AD-A022  053 


RAND  INTELLIGENT  TERMINAL  AGENT 
(RITA):  DESIGN  PHILOSOPHY 

R.  H.  Anderson,  et  al 

RAND  Corporation 


Prepared  for: 

Defense  Advanced  Research  Projects  Agency 


February  1976 


DISTRIBUTED  BY: 


National  Technical  Information  Service 
U.  S.  DEPARTMENT  OF  COMMERCE 


J 


Best 

Available 

Copy 


UNlXAbblHtU 


SECURITY  CLASSIFICATION  OF  THIS  f AC»  pThon  Ditm  Knfrod) 


REPORT  DOCUMENTATION  PAGE 

• READ  INSTRUCTIONS  1 

BEFORE  COMPLETING  FORM 

1.  REPORT  NUMBER 

R-1809-ARPA 

2.  GOVT  ACCESSION  NO. 

2.  RECIPIENT'S  CATALOG  NUMBER 

4.  TITLE  (mnd  ShHHIo) 

Rind  Intelligent  Terminal  Agent  (RITA):  Design 

Philosophy 

5.  TYPE  OF  REPORT  A PERIOD  COVERED 

interim 

6.  PERFORMING  ORG.  REPORT  NUMBER 

7.  author^; 

R.  H.  Anderson  and  J.  J.  Gillogly 

8.  CONTRACT  OR  G^ANT  NUMBER^*) 

DAHC1 5-73-C-0181 

8.  performing  organization  name  and  ADCRESS 

The  Rand  Corporation 
1700  Main  Street 
Santa  Monica,  Ca.  90406 

10.  PROGRAM  ELEMENT.  PROJECT.  TASK 
AREA  A WORK  UNIT  NUMBERS 

n.  controlling  office  t.  •••e  and  addrfss 

Defense  Advanced  Research  Projects  Agency 
Department  of  Defense 
Arlington,  Va.  22209 

?2.  REPORT  DATE 

February  1976 

13.  NUMBER  CF  PAGES 

<*X 

14.  MONITORING  AGENCY  NAME  a AOORESS (1!  dltlormnt  from  Controlling  Oltlco) 

15.  SECURITY  CLASS,  (ol  thle  report) 

UNCLASSIFIED 

15*.  DECLASSIFICATION'  DOWNGRADING 
SCHEDULE 

1 6'.  DISTRIBUTION  STATEMENT  (ot  thle  report) 


SECURITY  CL  ASSlMC  A MOW  OP  TmS  PAOCfWhw  Dmt»  Bnfr+d) 


A description  of  the  design  constraints,  design 
requirements,  and  overall  design  philosophy  gui r1  g 
the  implementation  of  the  Rand  Intelligent  Terminal 
Agent  (RITA).  PITA  is  a set  of  computer  programs 
residing  in  a PDP-11/45  minicomputer.  These  pro- 
grams are  capable  of  acting  as  a “user  agent" 
which  can  perform  a variety  of  tasks,  under  either 
direct  user  control  or  semi  autonomous  operation 
over  extended  periods  of  time.  The  RITA  system 
is  designed  to  be  widely  applicable  as  a stand- 
alone computing  resource  for  local  text  manipu- 
lation, as  a limited  heuristic  modeling  tool,  and 
as  a front  end  to  remote  computing  systems  and 
networks.  Operational  features  in  the  current 
(January  1976)  version  of  RITA  are  described. 
References.  (JDD) 


«» 

II 


ARPA  ORDER  NO.:  189- i 
6P10  Distributed  Information  Systems 


R-1809-ARPA 
February  1976 


’/•  ' / •’  ’1'  v,.  • * -v 


Rand  Intelligent  Terminal  Agent  (RITA): 

Design  Philosophy 

R.  H.  Anderson  and  J.  J.  Gillogly  \ 

\ 

u 

A 


A Report  prepared  for 

DEFENSE  ADVANCED  RESEARCH  PROJECTS  AGENCY 


REPRODUCED  BY 

NATIONAL  TECHNICAL 


INFORMATION  SERVICE 

U.  S.  DEPARTMENT  OF  ( OMMERCE 
SPRINGFIELD,  VA.  22U1 


APPROVED  FOR  PUBLIC  RELEASE;  DISTRIBUTION  UNLIMITED 


The  research  described  in  this  Report  was  sponsored  by  the  Defense  Advanced 
Research  Projects  Agency  under  contract  No.  DAHC15-73-C-G181.  Reports  of 
The  R«,nd  Corporation  do  not  necer ^arily  reflect  the  opinions  or  policies  of  the 
sponsors  of  Rand  research. 


-iii- 


PREFACE 

Members  of  Rand's  Information  Sciences  research  program  are  cur- 
rently implementing  a set  of  computer  programs  called  the  Rand  Intel- 
ligent Terminal  Agent,  or  RITA.  This  research  effort  is  part  of  a 
larger  research  program  on  advanced  intelligent  terminals  which  is  be- 
ing funded  and  coordinated  by  the  Information  Processing  Tech^ques  Of- 
fice (II lo)  of  the  Defense  Advanced  Research  Projects  Agency  (ARPA) . 

The  present  report  is  one  of  a series  documenting  the  design  and 
implementation  of  the  RITA  system.  It  presents  the  overall  design 
philosophy  guiding  the  work  in  progress,  and  is  intended  fo"*  a broad 
audience.  The  report  in  neither  highly  technical  nor  dependent  on  other 
reports  in  the  series . 

The  RITA  syater  Is  designed  to  be  widely  applicable  as  a stand- 
alone computing  resource  for  local  text  manipulation,  as  a limited 
leuristic  modeling  tool,  and  as  a front  end  to  remote  computing  systems 
and  networks.  As  such,  it  should  be  useful  to  persons  involved  with 
the  design  of  Interfaces  to  comput  *.r  networks  for  logistics,  maintenance 
scheduling  and  control,  command  and  control  systems,  intelligence  col- 
lection ar.d  dissemination,  and  remote  accessing  of  large  data  bases. 

It  should  also  be  relevant  for  designers  of  software  systems  supporting 
administrative  and  command  functions. 


The  Rand  Intelligent  Terminal  Agent  (RITA)  is  a set  of  computer 
programs  residing  in  a PDP-11/43  minicomputer.  These  programs  are  ca- 
pable of  acting  as  a "user  agent"  which  can  perform  a variety  of  tasks > 
both  under  direct  user  control  and  operating  semiautonomously  over'  ex- 
tended periods  of  time.  Among  these  tasks  are  (1)  filing,  retrieving, 
and  editing  of  data  on  local  storage  files,  (2)  handling  interactive 
dialogs  with  external  information  systems  available  over  either  tele- 
phone lines  or  the  ARPANET,  (3)  providing  local  tutorial  functions  and 
error -checking  of  input  data,  and  (4)  heuristic  modeling  of  a limited 
subjective  set  of  relationships. 

For  a user  agent  to  be  helpful  to  persons  who  are  not  programmers 
or  "computer  sophisticates,"  it  must  in  our  opinion  (1;  be  capable  of 
explaining  its  behavior  upon  request,  (2)  be  capable  of  having  its  be- 
havior modified  by  the  user  himself,  (3)  be  able  to  be  governed  by  sets 
of  heuristics  stated  as  rules,  rather  than  as  forma]  algorithms,  ard 
(4)  retain  a memory  of  tasks  assigned,  progress,  schedules,  and  dead- 
lines in  spite  of  either  scheduled  or  unscheduled  system  maintenance 
periods  or  "crashes"  (unplanned  system  failures  requiring  execution 
of  a restart  procedure) . Hi?.  RITA  system  meets  these  design  objectives 
primarily  by  using  production  systems:  sets  of  predicate-action  rule3 

operating  upon  a data  base  under  Jcie  guidance  of  a rule  interpreter, 
or  monitor. 

RITA’s  predicate-action  rules  are  stated  in  an  Englxsh-like  lan- 
guage having  a restricted  set  of  options.  The  data  base  consists  of 
a set  of  objects,  each  having  a set  of  named  attributes.  Each  attri- 
bute may  in  turn  have  either  a scalar  value  or  set  of  values  associated 
with  it.  The  form  of  the  rules  and  the  data  base  are  deliberately  sim- 
ple to  allow  understanding  of  their  structure  by  "compute r -naive"  users. 
Each  production  rule  may  be  thought  of  as  a heuristic  guiding  the  be- 
havior of  a user  agent.  The  RITA  monitor  is  capable  of  either  a 
pattern-directed  scan,  in  which  the  piedicates  of  rules  are  tested  for 
applicability,  or  a goal-directed  moae,  in  which  the  action  parts  of 
rules  are  scanned  for  relevance  in  achieving  a specified  goal. 
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The  RITA  system  design  consists  of  (1)  a kernel  containing  the 
monitor,  data  base,  and  rules,  and  (2)  a front-end  module  with  text- 
manipulation  capabilities  for  the  creation  and  editing  of  rules,  and 
a set  of  commands  tor  the  initiation,  interruption,  and  querying  of 
user  agents.  A basic  form  of  RITA  is  currently  operational,  but  work 
is  still  under  way  on  several  design  features  discussed  in  this  report. 
Several  examples  of  rule  sets  are  given  to  illustrate  both  pattern- 
directed  and  goal-oriented  * odes  of  operation. 
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GLOSSARY 


Algorithm 


ARPANET 


Backtracking 


Backward - 
chaining 


BNF 


Conflict  set 


Context 


A complete  set  of  instructions  sufficient  for  the 
accomplishment  of  a task.  It  is  usually  represented 
as  a computer  program  or  a set  of  s-.itements  in  a 
formally  defined  language. 

A nationwide  data  communication  netw  rk  using  leased 
telephone  lines  linking  over  50  computers  of  various 
types.  It  employs  a digital  "packet-switching" 
technique  allowing  shared  use  of  communication  lines. 

A method  of  operation  for  computer  programs  in  which 
failure  to  achieve  a desired  goal  leads  the  program 
to  "bac*  up"  and  try  some  other  alternative  at  an 
earlier  point  at  which  a choice  was  made.  Back- 
tracking is  used  by  the  RITA  monitor  when  an  attempt 
is  made  to  find  a correspondence  between  objects 
mentioned  in  the  pattern  part  of  rules  and  object! 
in  the  data  base.  If  a particular  binding  of  data 
objects  to  references  In  rules  has  been  made  by  the 
monitor,  and  some  later  predicate  is  found  to  be 
fals*_  for  that  particular  binding,  the  system  then 
backs  up  b',  una'ing  that  binding  and  trying  another 
binding  until  either  a successful  one  hes  been 
found  or  all  possible  bindings  have  been  tried. 

A mode  of  monitor  operation  in  a production  system 
in  which  the  next  rule*  to  be  applied  are  chosen 
because  their  action  parts  set  attribute  values 
tested  by  a (sub)  goal  rule.  Thus  a chain  of  rel- 
evant rules  is  created  "backward"  from  a designated 
goal  rule.  This  mode  of  operation  is  an  alterna- 
tive to  a pattern-directei  mode. 

"Backus-N*’  r Form"  — a formalism  for  describing 
gramma^  rules.  A set  of  such  grammar  rules  defines 
the  syntax  for  a formal  language.  (A  "formal 
language"  is  contrasted  with  a "natural  language" 
such  as  English,  for  which  no  known  finite  set  of 
grammar  rules  is  sufficient  to  describe  completely 
the  syntax  felt  to  be  "correct"  by  a native-born 
speaker. ) 

The  e< t of  production  rules  each  of  whose  pattern 
part  (LHS)  evaluates  to  "true"  at  a particular  time. 
One  or  more  of  these  rules  must  be  selected  for  the 
subseq  lent  execution. 

The  data  base  which  is  part  of  a production  system. 
In  RITA  it  contains  an  unordered  set  of  data  ob- 
jects, each  having  named  attributes  with  associated 
data  values. 
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Ccntext-free 


Goal-directed 


Heuristic 


Level  of 
certainty 


LHS 

LISP 


LR(1) 


Microprocessor 


Minicomputer 


A type  of  formal  language  whose  f.yntax  can  be  re- 
presented by  a simple  grammar.  See  Hopcroft  and 
Ullmsn  [1969]  for  a discussion  cf  fjrmal  language < 
and  their  properties 

A method  of  operation  in  which  the  behavior  of  a 
computer  program  is  governed  by  its  attempts  to 
achieve  a specified  goal.  It  J3ually  does  this  by 
deriving  a set  of  requisite  stbgoals  (and  sub- 
subgoals, etc.)  until  it  readies  a set  primitive 
tasks  which  can  be  accomplished. 

A ’'rule  of  thumb"  to  be  used  to  guide  behavior  (of 
a computer  system  or  a person) , but  which  is  not 
guaranteed  to  always  produce  the  desired  solution 
under  all  or  any  circumstances.  One  method  of  en- 
coding a heuristic  to  guide  a computer's  behavior 
might  be  as  a RITA  production  rule. 

A real  number  between  -1.0  and  1.0  (inclusive) 
which  can  be  associated  with  an  attribute  value  to 
indicate  the  degree  of  certainty  in  the  correctness 
of  that  value.  The  value  1.0  indicates  absolute 
certainty;  -1.0  indicates  certainty  that  the  given 
value  is  not  the  correct  one.  Ir  ermediate  values 
indicate  confirming  (+)  or  disconf inning  (-)  evi- 
dence has  been  amassed  for  a particular  value. 

Left-Hand  Side  of  a production  rule,  consisting  of 
predicates  to  be  evaluated. 

A computer  language  and  software  system  specializing 
in  the  storage  and  manipulation  of  data  consisting 
of  lists  of  items,  Each  item  may  be  either  a prim- 
itive value  or  itself  a list  of  items. 

An  acronym  for  "Left  to  Right  scan  with  1-symbol 
look-ahead."  This  is  a property  of  a grammar  de- 
fining the  syntax  of  a formal  lang”age.  Sentences 
in  a LR(1)  language  can  be  parsed,  or  interpreted, 
in  one  lef t-to-right  scan  of  the  symbols  comprising 
that  sentence  by  making  decisions  at  each  symbol 
encountered  based  only  on  the  sequence  of  symbols 
previously  encountered  and  in  addition  by  ’’looking 
ahead"  only  one  symbol  to  the  right  — i.e.,  to  the 
next  symbol  to  be  read. 

A computer  consisting  of  one  or  several  "chips" 
containing  laige-scale  integrated  (LSI)  circuits 
or  memory.  The  computer  would  thus  probably  be 
extremely  small  (e.g.,  several  cubic  inches,  ex- 
cluding such  components  as  the  power  supply) . 

A computer  of  modest  size  and  cost,  u3ual.lv  ranging 
in  price  between  $2000  and  $100,000. 
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Monitor 


MYCIN 


2W  York  Times 
Information 
Bank 


Object 


Pattern- 

directed 


PDP  11/45 


Production 

rule 


Production 

system 


A computer  program  which  evaluates  a set  of  produc- 
tion rules  by  testing  predicates  within  those  rules 
and  executing  the  corresponding  actions  specified 
in  rules  that  are  found  to  be  applicable. 

A computer  program  developed  by  E.  H.  Shortliffe 
and  associates  at  Stanford  University  that  advises 
physicians  regarding  antimicrobial  cnerapy  through 
an  interactive  dialog.  It  uses  production  rules 
and  a goal-directed  backward-chaining  mode  of  op- 
eration; it  is  written  in  LISP.  See  Shortliffe 
ec  al.  [1973,  1974a,  1974b,  1975a,  and  1975b]. 

An  information  retrieval  service  provided  by  a 
subsidiary  of  the  New  Yoik  Times  Corporation. 
Abstracts  of  .«r i icles  appearing  in  the  New  York 
Times  and  selected  other  publications  are  available 
ir  < igita1  form  via  telephone  lines  through  keyword- 
based  seaich  requests. 

In  the  RITA  system,  a datum  consisting  of  a name 
(or  type),  and  zero  or  more  named  attributes.  All 
attributes  associated  with  an  object  must  have 
mutually  distinct  names.  Each  attribute  has  an 
associated  value,  which  is  either  a character 
string  or  a set  of  values. 

A method  of  operation  for  production  systems  in 
which  the  operation  of  the  system  is  governed  by 
testing  of  the  pattern  part,  or  left-hand  side, 
of  the  production  rules.  Rules  whose  LHS  evaluate 
as  true  have  their  corresponding  action  part,  or 
RHS , executed. 

A minicomputer  produced  by  the  Digital  Equipment 
Corporation,  with  an  add  time  of  30C  nanosec  and 
maximum  addressable  storage  of  131,072  16-* it 

words . 

A statement  of  the  form: 

If:  predicate  & predicate  & ...  predicate 

12  m 

Then:  action  & action  & ...  ix  action 

12  n 

Depending  on  the  particular  strategies  incorporated 
in  the  rule  interpreter,  or  monitor,  the  actions 
are  (at  least  potentially)  performed  when  all  the 
predicates  are  true.  The  predicates  test  various 
objects  and  their  attribute  values  within  a data 
base,  or  context. 

A set  of  production  rules,  a rule  interpreter  (or 
monitor),  and  a data  base  (or  context). 


Protocol 


RHS 

RITA 


Syntax- 

directed 

parser 

UNIX 


The  set  of  commands  and  responses  which  constitute 
allowable  forms  of  communication  between  an  informa- 
tion system  and  an  external  jser  (which  may  be 
either  a person  or  another  information  system) . 

Right-Hand  Side  of  a production  rule,  consisting 
of  actions  to  be  performed 

Acronym  ror  Rand  Intelligent  Terminal  Agent,  a set 
of  computer  programs  residing  in  a PDP  11/45  mini- 
computer capable  of  acting  as  a "user  agent"  to 
perform  such  tasks  as  handling  interactions  with 
remote  information  systems  and  local  text  retrieval 
and  storage. 

A computer  program  which  receives  as  input  the 
formal  grammar  for  a language  (usually  in  the  form 
of  a set  of  rules),  and  interprets  strings  of 
characters  according  to  the  rules  in  that  grammar. 

An  operating  system  for  the  PDP-11  minicomputer 
developed  at  Bell  Laboratories.  See  Ritchie  and 
Thompson  [1974]. 
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I.  INTELLIGENT  TERMINALS 


This  repoit  discusses  a design  philosophy  for  a set  of  computer 
programs  expected  to  reside  in  an  intelligent  terminal.  The  programs 
comprise  what  we  call  the  Rand  Intelligent  Terminal  Agent,  or  RITA. 

What  is  an  "intelligent  terminal  agent"  and  why  is  it  useful?  The 
answer  involves  many  aspects  of  the  way  people  interact  with  computer 
systems  as  well  as  new  alternatives  becoming  possible  through  advances 
in  both  hardware  and  software  technology.  The  following  observations 
concerning  man/machine  interaction  and  its  supporting  technologies 
form  the  basis  for  our  research: 

1.  Until  recently,  most  users  of  information  systems  have  been 
either  "computer  sophisticates"-'  such  as  computer  programmers — or  else 
users  of  systems,  such  as  airline  reservation  systems,  with  a very  lim- 
ited eet  of  options.  However,  with  the  continuing  rapid  decline  in  the 
cost  of  computer  hardware  and  data  communications,  many  interactive 
computer-based  information  systems  are  becoming  cost  effective  for  much 
broader  categories  of  users.  These  newer  systems  will  greatly  expand 
the  number  of  people  interacting  with  computers  in  their  daily  activi- 
ties, and  will  give  access  to  a complex  variety  of  interactive  proto- 
cols, interfaces,  command  languages,  and  remote  confuting  systems. 

People  are  going  to  need  assistance  in  tailoring  thi9  variety  of  options 
to  their  specific  needs  and  especially  in  freeing  them  fvom  routine  in- 
teractions and  protocols  which  are  not  d< lectly  relevant  to  the  content 
of  their  task. 

2.  Projected  computer  hardware  cost  trends  and  advances  in  micro- 
processor fechnology  make  it  extremely  likely  that  interactive  computer 
terminals  can  be  produced  within  five  fo  seven  years  containing  equiva- 
lent processing  power  to  a present-day  minicomputer,  at  a cost  which 

is  reasonable,  assuming  fairly  intensive  use  of  dedicated  terminals  by 
professionals  as  part  of  their  job. 

3.  It  is  important  to  have  certain  information  storage  and  handl- 
ing capabilities  locally  within  the  terminal  itself: 
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o Text  editing  and  auxiliary  functions  such  as  the  retrieval 
and  storage  of  textual  information  which  is  currently  in 
use.  This  service  should  be  provided  locally  for  the  follow- 
ing reasons: 

High  speed,  reliable  response . A local  processor 
can  give  "instantaneous"  feedback  to  simple  commands 
(e.g.,  the  "display  next  line"  button)  and  such  user  ac- 
tions ns  stylus  pointing  or  dragging.  A remote  time- 
shared  computer  cannot  always  give  such  immediate  feed- 
back, and  the  response  time  tends  tc  be  somewhat  erratic. 

hotter  cos t . Through  stand-alone  operation  for  many 
text-manipulation  operations , uae  of  external  computers 
and  communication  systems  can  be  minimized.  Also,  routine 
processing  requiring  the  use  of  remote  systems  (e.g., 
for  archival  storage  and  retrieval  of  documents)  can  be 
initiated  by  an  intelligent  terminal  during  off-peak 
hours,  when  lower  rates  are  usually  in  effect.  We  expect 
that  within  about  five  years  these  savings  will  more  than 
offset  the  coat  of  an  intelligent  terminal,  at  least  un- 
der conditions  of  intensive  use. 

Reliability . There  are  fewer  serial  components, 
each  of  which  must  be  in  operation,  for  the  system  to 
be  functional.  (For  example,  use  of  a remote  text  edi- 
tor on  ARPANET  typically  requires  a local  host,  local 
Interface  Message  P-ccessor  (IMP),  communication  path, 
remote  IMP(s),  remote  host — all  simultaneously  opera- 
tional.) 

Security . A terminal  with  local  processing  power 
can  perform  many  needed  data-manipulation  operations  in 
a "locked  office"  stand-  alone  mode,  witn  no  information 
transmission  susceptible  to  compromise, 
o Handling  tutorial  functions,  answering  queries  for  help,  pro- 
viding exercises,  and  giving  local,  imme ’iate -feedback  error- 
checking on  input  commands  and  data.  Immediacy  of  response 
(e.g.,  to  simple  input  error  conditions)  Is  our  primary  reason 
for  advocating  that  these  functions  be  provided  locally. 
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If  local  computing  power  is  available  within  a terminal,  several  other 
services  can  be  provided  at  a small  incremental  cost.  Such  services 
could  include: 

o Aid  in  interfacing  with  external  information  systems,  such 
as  the  ARPANET  or  New  Ynrk  Tines  Information  Bank,  where  much 
of  the  interactive  protocol  involves  supplying  standard  re- 
sponses which  are  not  directly  relevant  to  the  task  being  ac- 
complished. It  should  be  possible  to  instinct  an  intelligent 
terminal  how  to  handle  ouch  interactive  protocols  automati- 
cally, including  instructions  on  dealing  with  certain  error 
conditions,  so  that  these  details  need  not  be  remembered  and 
handled  manually  by  the  us  r. 

o The  ability  to  define  and  set  in  motion  ’’user  agents.”  Such 
an  agent  could: 

Look  at  a calendar  cf  events  and  start  up  services 
for  the  U3er  automatically  at  certain  times  and  dates. 

By  manipulating  calendar  items,  the  human  manager  can 
progressively  modify  the  plan  being  executed  by  the  ma- 
chine. For  example,  by  changing  the  due  drte  of  a report, 
the  schedule  will  be  automatically  altered  for  reminders 
and  follow-up  queries  to  persons  making  contributions. 

It  cfin  monitor  the  occurrence  of  various  types  of 
events,  such  as  the  arrival  of  a certain  piece  of  net- 
work "mail,”  or  the  occurrence  of  a certain  datum  in  a 
changing  data  base. 

It  can  deliver  "interactive  letters"  to  other 
users’  terminals;  these  letters  are  capable  of  carrying 
on  a dialog' with  the  recipient,  while  in  the  process  ex- 
tracting information  from  him  ir  a standard  format  suit- 
able for  further  automated  processing.  Figure  1 illus- 

★ 

trates  the  possible  operation  of  an  interactive  letter. 

* 

The  idea  of  an  interactive  letter  and  the  type  of  dialog  shown  in 
Fig.  1 arc  taken  from  an  unpublished  manuscript  by  Thomas  A.  Standlsh 
(U.C.  Irvine),  entitled  "Scenarios  for  Use  of  an  Intelligent  Terminal," 
August  l'L,  1974. 
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Jones  finds  a message  on  pis  intelligent  terminal 
indicating  that  an  interactive  letter  has  been  received 
from  Jane  Smith.  Jones  Activates  the  terminal  and  it 
starts  to  type: 

Dear  Bill, 

It  is  time  to  make  plans  for  next  year's  project 
budget,  and  Jack  asked  me  to  coordinate  everything  this 
year.  It  would  be  helpful  if  you  could  answer  a few 
questions : 

How  many  trips  to  the  East  Coast  do  you  expect  will  be 
required  by  you  and  members  of  your  staff?  Numbor= 


Here  the  letter  stops  for  Jones  to  indicate  his  answer. 

He  places  a quick  telephone  call  to  a key  subordinate  to 
verify  his  plans,  then  adds  other  trips  he  knows  will  be 
necessary,  and  types  in  "6M.  The  letter  continues: 

Please  give  the  names  of  consultants  you  expe  to  use 
during  th°  next  >ear,  and  the  numbei  of  days'  support 
required  for  each  of  them.  (When  the  list  is  finished, 
respond  to  "Name"  with  a carriage  return.)  Name= 


Bill  looks  at  his  plans  for  the  forthcoming  year,  calls  a 
consultant  whose  availability  was  uncertain  at  their  last 
discussion,  then  types  "A.C.  Johnson".  The  letter  responds: 

//  days= 


Bill  types  "20",  then  repeats  the  cycle  for  several  more 
consultants,  finally  terminating  with  a carriage  return  as 
a response.  The  letter  then  continues: 

What  is  your  estimate  of  your  requirements  for  computer 
services  during  the  forthcoming  year?  Please  give  a 
dollar  amount.  Answer= 


Bill  types  "$48,000."  and  the  letter  concludes: 

Thank  you  for  your  help.  T hope  to  have  a draft  proj°ct 
budget  in  your  hands  for  review  by  next  Wednesday. 

Regards , 

Jane  Smith 


Fig.  1 — Illustration  of  die  cperation 
of  an  interactive  letter 
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It  could  be  responsible  for  managing  transactions 
between  a number  of  computerized  services  distributed 
cn  a computer  network,  monitoring  their  successful  ac- 
complishment . 

Ue  believe  that  the  desirability  of  the  above  list  of  services  is 
a compelling  reason  to  explore  the  design  of  intelligent  terminal 
agents  capable  of  running  in  present-day  minicomputers.  Our  work  on 
the  RITA  system  is  aimed  at  developing  a prototype  agent  system  capable 
of  performing  all  of  the  above  activities. 

What  specific  system  design  requirements  are  implied  by  the  above 
discussion?  The  next  two  sections  of  this  report  list  several  design 
constraints  within  which  this  research  is  being  conducted.  Then,  in 
that  context,  we  itemize  a set  of  design  requirements  for  an  Intelligent 
terminal  agent  which  we  have  distilled  from  the  general  characteristics 
described  above;  these  requirements  are  the  basis  for  our  design  deci- 
sions during  the  implementation  of  the  RITA  system. 
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II*  DESIGN  CONSTRAINTS 


There  are  a number  of  constraints  on  our  design  and  development 
of  an  intelligent  terminal  agent  which  are  a natural  consequence  of 
such  factors  as  our  source  of  funding  and  available  computational  re- 
sources. Some  of  the.  most  important  of  these  are  listed  below. 

X.  Tills  research  is  being  funded  by  ARP.—  TPTO  because  of  its 
prospective  benefits  to  the  Department  of  Defense  (DOD) . A particular 
user  group  within  DOD  targeted  by  ARPA-IPTO  as  an  initial  testbed  for 
intelligent  rerminrl  systems  is  analysts  within  the  intelligence  com- 
munity. We  therefore  view  our  initial  RITA  system  as  an  intelligence 
analyst's  station,  and  characteristics  of  this  user  group  (e.g.,  well- 
educated  and  requiring  text-manipulation  tools  and  access  to  a variety 
of  external  information  systems)  have  influenced  our  design  decisions. 

2.  Because  our  concept  of  an  intelligent  terminal  agent  presup- 
poses minicomputer -like  power  becoming  locally  available  to  a user, 
the  RITA  system  must  be  capable  of  running  in  a present- day  minicompu- 
ter. An  additional  reason  for  developing  RITA  in  an  existing  mini- 
computer is  that  the  software  might  be  capable  of  transfer  directly 
into  a terminal  of  the  future,  if  that  terminal's  built-in  computer 
copies,  or  emulates,  the  instruction  set  and  architecture  of  RITA's 
present  host  machine. 

3.  There  is  a PDP  11/45  minicomputer  at  Rand  for  computer  re- 
search. It  runs  the  UNIX  operating  system  [Ritchie  1974]  (developed 
at  Bell  Laboratories)  which  supplies  many  relevant  facilities,  such 
as  time-sharing,  interprocess  communication,  a system  programming 
language  (celled  "C”)  with  many  advanced  facilities,  a hierarchical  file 
system,  and  so  forth.  The  PDP  11/45  with  UNIX  is  the  obvious  choice 
for  the  initial  implementation  of  RITA. 

4.  An  interactive  man/machine  interface  called  the  Rand  Editor 
is  under  concurrent  development  at  Rand  on  the  PDP  11/UNIX  system. 

This  editor  pro /idee  excellent  two-dimensional  cursor-controlled  text- 
manipulation,  editing,  and  storage  facilities.  We  expect  to  integrate 
the  Rand  Editor  with  the  production  system  described  in  thi3  report  to 
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produce  a more  complete  RITA  system  which  will  allow  use  of  the  text 
editing  facilities  for  the  creation  and  modification  of  production 
rules.  The  "text  wini-jw"  concept  embodied  within  the  Rand  Editor 
should  provide  multiple  windows  for  communication  with  one  or  more  user 
agents,  possibly  running  concurrently  under  the  control  of  production 
system  monitors.  (A  recent  doctoral  thesis  by  Swinehart  [1974]  pro- 
poses a similar  but  more  elaborate  form  of  inte  active  user  interface 
with  multiple  concurrent  processes.) 
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III.  DESIGN  REQUIREMENTS  FOR  AN  INTELLIGENT  TERMINAL  AGENT 

We  have  extracted  the  following  specific  design  requirements  from 
the  d-J°cussIon  of  general  features  in  Sec.  I,  taking  i:.to  consideration 
the  constraints  listed  in  Sec.  II. 

1.  Most  users  of  such  terminal  agents  will  be  computer-naive. 

They  will  be  given  a terminal  system  which  has  been  tailored  to  the 
perceived  needs  of  a closs  of  users  by  application  specialists  who  are 
expected  also  to  have  programming  skills.  This  basic  system  must  be 
capable  of  performing  actions  for  the  user  and  of  explaining  its  be- 
havior, upon  request.  (We  feel  that  a computer-naive  user  will  not 
trust  an  intelligent  terminal  agent  to  perform  complex  tasks,  such  as 
logging  into  remote  computer  systems  for  him  to  transfer  data  out  of 
his  "mail"  files,  without  his  being  able  to  the  agont  what  actions 
were  tak^n,  and  why.) 

2.  There  must  be  a language  through  which  the  behavior  of  the 
agent  can  be  modified  and  extended  by  a user.  Traditional  programming 
languages  do  not  seem  appropriate  for  this  purpose  because: 

o The  user  will  probably  not  b<  a programmer. 

o The  user  is  not  expected  to  think  in  terms  of  algorithms  as 
a mea^s  of  instructing  his  terminal  agent,  but  rather  in  terms 
of  sets  cf  rules,  or  heuristics,  in  accordance  with  which  it 
should  operate.  (These  Heuristics  w*ll  be  supplied  explicitly 
by  the  user,  at  least  in  initial  vevplw.*  of  the  system;  in 
later  versicr.s,  the  system  might  be  capable  of  acquiring  new 
rules  by  example  or  through  induction.) 

o The  nested  control  structures  of  programming  languages  are 
unnatural  and  a source  of  error  to  computer- naive  persons 
(see  Miller  1975  for  a further  discussion). 

3.  The  agent  must  be  capable  of  two-way  communication  both  with 
the  user  and  with  external  systems  (e.g.,  over  dia]-up  telephone  lines 
or  an  ARPANET  connection) . 
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4.  It  must  be  capable  of  running  in  a minicomputer. 

5.  The  s'  tem  must  be  capable  of  retaining  a "memory " of  tasks 
assigned,  schedules,  deadlines,  and  so  forth  in  spite  of  scheduled 
maintenance  periods  or  unscheduled  system  crashes. 

6.  The  system  should  allow  the  retrieval,  editing,  and  storage 
of  text,  and  have  an  understanding  of  calendar  and  clock  time  to  form 
the  basis  for  handling  appointments,  scheduling,  and  other  time- 
managewent  tools. 
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IV.  PRODUCTION  SYSTEMS  AS  THE  BASIS  FOR  A TERMINAL  AGENT 


The  basis  for  our  deeign  of  a systeir  meeting  the  above  requirements 
it 3 the  use  of  production  systems.  A production  system  consists  of  a 
set  of  production  rules,  which  operate  upon  a data  base  (which  we  call 
a context) , according  to  the  actions  of  a rule  J . erpreter,  or  monitor. 

For  example,  two  production  rules  might  be: 

Rule  1 

IF:  there  is  a message  whose  status  is  "awaiting  action"  and 

the  identification-field  of  the  message  is  not  in  the  set 
of  action-item.3  of  the  user 

THEN:  put  the  identification-f ie] d of  the  message  in  the  set  of 

action-items  of  the  user; 

Rule  2 

IF:  The  latest-command  of  the  user  is  "show  action  items"  and 

the  state  of  the  system  is  "command  unfulfilled" 

THEN:  send  the  set  of  action-items  of  the  user  to  the  user  and 

set  the  state  of  the  system  to  "command  fulfilled"; 

These  rules  would  be  part  of  a larger  set  of  rules  governing  a 
a message-handling  user  agent.  They  might  be  interpreted  by  a monitor 
that  continually  tests  the  "if"  conditions  in  each  rule  of  the  set, 
and  executes  the  "then"  actions  in  any  rule  whose  conditions  are  all 
true.  Assuming  messages  with  various  attribute  values,  such  as  an 
identification  field  and  status,  are  placed  in  the  data  base  by  some 
external  (and  possibly  asynchronous)  process,  the  above  rules  would 
update  a set  consisting  of  the  identification  numbers  of  all  messages 
awaiting  action,  and  show  that  set  to  the  user  upon  his  request.  Other 
rules  would  themselves,  or  permit  the  user  to,  take  other  actions  and 
as  a consequence  change  the  status  of  the  messages  and  remove  their 
identification  numbers  from  the  set  of  action  items. 

In  the  remainder  of  this  section,  we  discuss  some  of  the  options 
available  in  designing  a particular  production  system,  itemize  the 
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advantages  we  see  accruing  from  their  use,  and  then  discuss  the  partic- 
ular design  decisions  we  have  made  in  the  choice  of  rule  format,  moni- 
tor, and  format  of  a context  data  base  for  the  RITA  system,  The  ap- 
pu^dix  to  this  report  contains  some  examples  of  RITA  rule  sets  and 
traces  of  their  operation.  Our  discussion  generally  follows  that  given 
in  the  recent  excellent  survey  article  on  production  systems  by  Davis 
and  King  [1975]. 

DESIGN  OPTIONS  IN  THE  USE  OF  PRODUCTION  SYSTEMS 

There  is  considerable  variety  in  existing  production  system  ap- 
plications. The  options  available  can  be  discussed  under  the  headings 
of  their  three  main  components:  context  data  base,  rules,  and  monitor. 

Context  Data  Base 

The  simplest  form  of  a context  on  which  rules  may  operate  is  a 
string  of  symbols.  The  rule  tests  for  the  existence  of  a substring 
within  the  context,  and  supplies  a replacement  string  to  be  substituted 
for  it  if  found.  At  the  other  extreme,  the  data  base  may  be  a complex 
semantic  network  or  other  form  of  structured  data  base  within  which 
rules  test  for  patterns  and  upon  which  rule  actions  perform  operations. 
The  former  type  (i.e.,  string  substitution)  is  often  used  by  cognitive 
psychologists  to  model  low-level  cognitive  information  manipulation 
processes.  Production  systems  which  operate  on  complex  data  structures 
tend  to  have  complex  rules  which  are  difficult  for  either  humans  or 
other  computer  programs  to  decipher.  This  would  be  counter  to  the 
spirit  of  the  production  system  approach.  Therefore,  such  systems  must 
be  designed  with  great  care. 

An  intermediate  form  of  data  complexity  which  has  been  found  to 
be  useful,  e.g.,  in  che  MYCIN  system  developed  by  E.  H.  Shortliffe  and 
associates  at  Stanford  University  [1973,  1974a,  1974b,  1975a,  1975b], 
is  a context  consisting  of  a set  of  objects , each  of  which  has  an  as- 
sociated set  of  named  attributes , with  each  attribute  having  an  as- 
sociated value , or  set  of  values.  This  form  of  data  has  been  used  in 
innumerable  LISP  programs  and  is  embodied  in  the  property  list  mechan- 
ism in  that  language.  It  is  also  a data  form  used  in  relational  data 
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bases  , where  each  item  of  information  is  atored  as  a triple  (attribute, 
object,  value).  In  this  general  data  form,  there  are  many  design  de- 
cisions to  be  made  which  affect  the  resulting  complexity  of  the  data 
base  and  the  complexity  of  the  actims  needed  to  operate  upon  that 
data.  Some  options  are 

o Can  attributes  take  a single  value?  Or  a set  of  values?  If 
a set,  is  it  unordered  or  ordered,  and  what  accessing  options 
are  available  for  testing  values  and  replacing  values  within 
the  set? 

o Is  an  attribute  value  a scalar  quantity?  Or  can  it  be  (a 

poirLer  to)  another  object?  T.l  the  latter,  then  the  attribute 
acts  as  a named  relation  between  two  objects,  but  without  re- 
strictions this  feature  can  result  in  a data  base  having 
pointers  which  form  an  arbitrarily  complex  di  ected  graph. 

o Is  there  an  external  structure  imposed  on  the  objects  in  the 
context?  The  MYCI.N  sy  tern,  for  example,  has  found  it  useful 
to  place  objects  in  a tree-structured  context;  this  allows 
incompletely  specified  object  references  within  rules  to  be 
bound  to  the  "nearest"  object  within  the  tree  to  the  location 
at  which  the  rule  is  currently  operating. 

o Can  an  attribute  value  have  a probability  or  confidence  level 
associated  with  it? 

o Do  all  objects  have  a unique  indentifier  associated  with  them? 
If  not  (for  example,  if  there  can  be  numerous  instances  in  the 
data  base  of  an  object  called  "block"),  then  how  are  specific 
objects  referenced?  Once  a certain  object  has  been  referenced 
by  one  rule,  can  that  reference  be  passed,  either  explicitly 
or  implicitly,  to  other  rules' 

o Can  objects,  and  attributes  of  existing  objects,  be  created 
and  deleted  dynamically  by  the  actions  of  rules? 

Rules 

A production  rule  consists  of  a left-hand  side  (LHS)  or  pattern 
part,  and  a right-hand  side  (RHS)  or  action  part.  The  pattern  part  of 
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i rule  chosen  by  the  monitor  is  evaluated  with  respect  to  the  current 
context.  If  it's  true,  the  :orret>ponding  action  part  \s  executed,  and 
another  rule  is  chosen  for  evaluation.  If  it’s  f..lse,  the  actions  are 
not  executed,  and  another  rule  is  chosen.  The  simplest  form  cf  rule 
consists  of  symbol  strings  as  both  LHS  and  RHS,  as  mentioned  above. 

In  this  case,  the  context  is  a string,  and  the  evaluation  of  the  LHS 
is  merely  a check  whether  the  LHS  is  a substring  of  the  context  string. 
If  so,  that  substring  is  replaced  by  the  corresponding  RHS. 

The  most  general  form  of  a rule  contains  arbitrary  predicates  on 
the  LHS,  with  on<.  or  m: re  arbitrary  function  calls  on  the  RHS.  The 
predicates  test  :or  the  existence  of  certain  data,  or  relationships 
among  data,  within  the  data  base.  The  function  calls  on  the  rule’s 
RHS  make  changes  to  the  data  base  (and  perhaps  perform  other  actions 
as  "side  effects,"  such  as  emitting  messages  to  external  processes). 

Several  other  options  in  the  form  of  rules  are  noteworthy: 

o String  pattern/replacement  rules,  allowing  variables  and  "don’t 
care"  symbols  as  part  of  the  pattern  and  replacement  strings. 
These  rules  are  not  unlike  SNOBOL  [Griswold  1973]  statements. 

o Use  of  a stylized,  limited  language  capable  of  interpretation 

* 

by  a context-free  syntax-directed  parser  for  expressing  predi- 
cates and  actions.  This  language  might  allow  certain  options 
in  testing  and  changing  the  context  data  base,  but  would  not 
permit  arbitrary  tests  and  actions  whose  effects  on  the  data 
base  could  not  be  interpreted  by  the  monitor  itself. 

o An  option  similar  to  that  above,  but  with  a natural-language 
front  end  capable  of  understanding  rules  v ;itten  by  a user  in 
natural  English  and  of  translating  them  into  a stylized  set  of 
predicates  and  actions.  (This  option  is  exemplified  by  the 
MYCIN  system.) 

Other  options  to  be  considered  in  the  design  of  rules  for  a pro- 
duction system  are: 

o Whether  the  rules  are  to  be  used  in  a goal -directed  or  pattern- 
directed  manner.  A goal-directed  system  has  a designated  goal, 
and  the  objective  is  to  execute  rules  whose  actions  achieve 

_ 

These  technical  terms  are  contained  in  the  Glossary. 
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that  goal.  A pattern-directed  system,  on  the  other  hand,  merely 
tests  the  pattern  part  of  rales  chosen  according  to  some  scheme 
by  the  monitor  against  the  current  context , and  applies  (one  or 
more  of)  these  that  match.  To  some  extent,  rules  must  be  de- 
signed to  operate  according  to  the  characteristics  of  a particu- 
lar monitor.  For  example,  rules  used  in  a goal-directed  system 
should  not  have  act.’ on  clauses  causing  side  effects.  Such  side 
effects  often  cannot  be  undone  when  backtracking  to  try  an  alter- 
native path  in  pursuit  of  the  goal.  The  various  monitor  options 
are  discussed  in  the  following  subsection, 
o The  degree  to  which  the  rules  capture  discrete  pieces  of  know- 
ledge. It  is  advantageous  in  production  systems  to  have  the 
rules  as  independent  of  each  other  as  possible,  since  one  of 

! 

the  prime  motivations  for  expressing  process  descriptions  in 
rule  form  is  to  be  able  to  modify  those  descriptions  easily, 

1 

and  possibly  even  automatically.  If  rules  do  not  capture  dis- 
crete pieces  of  knowledge,  so  that  they  may  be  added  or  removed 
easily  without  destroying  the  logic  of  the  system,  then  many  of 
the  advantages  are  lost. 

o The  readability  of  the  rules.  Are  the  rules  meant  for  machine 
consumption  only,  or  ror  human  readability  also?  An  example  of 
the  former  might  be: 

FUN  1(a.)  & FUN  3(2)  =•'  EXEC(G(X))  ; 

An  example  of  the  latte r might  be: 

IF:  the  prompt  character  of  the  remote  _system  is 

THEN:  the  name  of  the  remote  system  . - "tenex"  (P=,7); 

o What  is  stored  in  rule  form?  it  is  most  natural  to  state  heu- 
ristics in  the  form  oi  rules,  but  it  is  also  possible  to  store 
data  (e.g.,  "if  he  asks  for  x,  give  him  y")  and  control  informa- 
tion (e.g.,  rules  for  choosing  the  next  rule  to  test), 
o Are  ail  rules  potentially  applicable  at  all  times,  or  is  their 
aDpiicah i 1 Lty  limited,  for  example,  by  partitioning  them  (either 
automatically  or  explicitly  by  the  user)  into  sets,  only  one  of 
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which  Is  applicable  at  any  time?  (Another  method  of  limiting 
the  applicability  of  rules  is  through  ordered  rule  sets,  in  which 
the  applicability  of  a rule  is  governed  by  its  position  within 
that  ordered  set.) 

Monitor 

This  discussion  of  monitor  design  options  closely  follows  that 
given  by  Davis  and  King  [1975].  The  basic  control  cycle  performed  by 
a monitor  consists  of  two  phases:  recognition  and  action . The  recog- 

nition phase  involves  selecting  a single  rule  for  execution,  and  can 
be  further  subdivided  into  selection  and  conflict  resolution . In  the 
selection  process,  one  or  more  potentially  applicable  rules  are  chosen 
from  the  set  and  passed  to  the  conflict  resolution  algorithm,  which 
chooses  one  or  more  of  them  for  execution.  The  options  in  monitor 
design,  then,  can  be  discussed  in  terms  of  the  above  categories. 

Selection . Rules  can  be  selected  by  a LHS  scan  or  a RKS  scan. 

In  a LHS  scan,  each  rule  LHS  is  evaluated  in  turn.  If  this  process 
stops  at  the  first  successful  evaluation  encountered,  then  conflict 
resolution  is  trivial.  It  is  possible,  however,  to  collect  (into  a 
set  called  the  conflict  set)  all  rules  whose  LHSs  evaluate  successfully. 
(It  is  in  fact  possible  to  have  multiple  occurrences  of  a single  rule 
in  the  conflict  set,  if  more  than  one  set  of  bindings  between  objects 
and  attributes  mentioned  In  the  rule  and  data  objects  occurring  in  the 
context  make  the  rule’s  LHS  evaluate  successfully.)  It  is  then  neces- 
sary co  perform  conflict  resolution  to  choose  the  rule(a)  for  execution 
from  this  set. 

Selection  by  a RHS  scan  can  be  considered  a form  of  goal-oriented 
operation.  One  specific  item  of  Information  (an  attribute  of  an  object) 
is  designated  as  a goal . The  goal  of  the  system  operation  is  to  ex- 
ecute the  actions  on  the  RHS  of  rules  that  set  this  attribute  value. 

To  this  end,  the  LHSs  of  those  rules  are  evaluated.  If  any  such  LHS 
clause  refers  to  an  Item  of  information  not  yet  in  the  context  data 
base,  obtaining  that  item  becomes  a subgoal.  A RHS  scan  is  performed 
to  find  all  rules  that  contain  in  their  RHS  an  action  clause  which 
creates  that  item  of  Information.  All  rules  meeting  this  criterion 
are  placed  In  the  conflict  set.  This  form  of  RHS  scan  Is  best 
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exemplified  by  the  operation  of  the  MYCIN  3ystem  of  E.  Shortliffe  et  al. 
Interested  readers  are  referred  to  the  excellent  description  of  MYCIN’ s 
operation  contained  in  Shortliffe's  recent  Ph.D.  thesis  [1974b]. 

Conflict  resolution . If  a conflict  set  has  been  created  during 
the  rule  selection  process,  conflict  resolution  is  necessary  to  choose 
which  rule(s)  in  that  set  should  be  executed.  Several  possible  cri- 
teria for  conflict  resolution  (suggested  by  Don  Waterman  of  Rand)  are: 

o Rule  order.  There  is  a complete  ordering  of  all  rules  in  the 
system,  and  the  rule  in  the  conflict  set  with  the  highest 
priority  is  chosen. 

o Data  order.  Elements  of  the  data  base  are  ordered,  and  that 
rule  is  chos  in  which  matches  elements  in  the  data  base  with 
highest  priority. 

o Generality  order.  The  most  specific  rule  is  chosen. 

o Rule  precedence.  A precedence  network  (perhaps  containing 
cycles)  determines  the  hierarchy. 

o Recency  order.  The  most  recently  executed  rule  is  chosen, 
or  the  rule  containing  the  most  recently  updated  element  of 
the  data  base. 

It  is  not  necessary  that  only  one  rule  be  chosen  for  execution 
from  the  conflict  set.  In  MYCIN,  for  example,  action  clauses  in  rules 
contain  a certainty  factor  when  creating  an  item  of  information.  MYCIN 
executes  all  rules  in  the  conflict  set,  using  the  combined  certainty 
factors  to  achieve  a combined  judgment,  which  is  reflected  by  data 
values  (with  associated  resultant  certainty  factors)  in  the  context 
data  base . 

Action.  There  are  few  options  associated  with  the  execution  of 
action  clauses  of  successful  rules  by  a monitor.  Most  actions  set  con- 
text data  values  for  suosequent  testing  by  other  rules.  In  production 
systems  it  is  considered  poor  for  actions  to  have  complicated  side 
effects  or  to  execute  arbitrarily  complex  programs,  although  side  ef- 
fects are  sometimes  necessary  to  perform  such  actions  as  communication 
with  an  external  process  or  system.  One  control-type  action  sometimes 
allowed  is  transfer  of  control  to  a different  set  of  rules,  which  can 
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be  consider ad  another  ’’state"  of  the  system,  in  which  the  behavior  of 
the  system  in  each  state  is  governed  by  a rule  set.  The  VIS  system  of 
Moran  [1973]  is  one  example  of  a system  allowing  such  clustering  of 
rules . 

Before  discussing  the  particular  design  decisions  we  have  made, 
choosing  from  the  large  selection  of  options  listed  above,  we  will 
consider  next  the  advantages  to  be  gained  from  using  a production  sys- 
tem. The  priorities  we  placed  on  certain  advantages  have  had  an  im- 
portant effect  on  our  design  decisions. 


ADVANTAGES  OF  PRODUCTION  SYSTEM  USE 

The  following  advantages  are  often  cited  as  accruing  from  the  use 
of  production  systems.  We  have  listed  them  in  what  we  believe  is  an 
approximate  decreasing  order  of  importance  for  the  particular  applica- 
tion for  which  RITA  is  designed:  namely,  the  construction  of  Intelli- 

gent terminal  agents. 

1.  Their  explanatory  capability . 


Production  system  rules  are  intended  to  be  mod- 
ular chunks  of  knowledge  and  to  represent  primi- 
tive actions.  Thus,  explaining  primitive  acts 
should  be  as  simple  as  stating  the  corresponding 
rule — all  necessary  contextual  information  should 
be  included  in  {.he  rule  itself.  Achieving  such 
clear  explanations,  however,  evidently  strongly 
depends  upon  thi  extent  to  which  the  assumptions 
of  modularity  and  explicit  context  are  met. 

[Davis  and  King  1975] 


Figure  2 contains  an  example  taken  from  Shortliffe  [1975]  of  the  highly 
advanced  explanatory  capability  of  the  MYCIN  system.  MYCIN  is  an  excel 
lent  example  of  the  degree  of  explanatory  power  that  can  be  achieved 
through  careful  design  and  implementation. 

2.  Simple  control  structure . Experiments  conducted  by  Miller 
[1975]  on  various  methods  of  transfer  of  control  in  programming  lan- 
guages have  shown  that  ir-then-else  nested  conditionals  and  branch-to- 
label  control  structures  are  serious  sources  of  programming  error. 
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MYCIN:  In  light  of  the  site  from  which  the  culture  was 

obtained,  and  the  method  of  collection,  do  you 
feel  that  a significant  number  of  ORGANISM-1 
were  obtained? 

”SER:  Why? 

MYCIN:  [i.e.r  Why  is  it  important  to  determine  if  a 

significant  number  of  ORGANISM  1 were  obtained?] 

1.0]  It  is  important  to  find  out  whether  there  is 
therapeutically  significant  disease  associated  with 
this  occurrence  of  ORGANISM-1. 

It  has  already  been  established  that 

1. 1]  the  site  of  the  culture  is  not  one  of  those 
which  are  normally  sterile,  and 

1.2]  the  method  of  collection  was  sterile. 
Therefore,  if 

1.3]  the  organism  has  been  observed  in 
significant  numbers 

then  there  is  3trongly  suggestive  evidence  (.9)  that 
there  is  therapeutically  significant  disease 
associated  with  this  occurrence  of  the  organism. 
[ALSO:  there  is  btrcngly  significant  evidence  (.8) 

tnat  the  organicm  is  not  a contaminant.] 
(RULE042) 

The  user  may  then  query  further  about  why  this  information 
is  important  (1.0]),  in  which  case  MYCIN  would  give  a 
similar  explanation  based  on  the  rule  that  called  this  one. 


Fig.  2 — Illustration  of  the  explanatory  capability 
of  the  MYCIN  system 
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Miller  also  reports  that  a "procedure  table"  specification  of  control 
led  to  much  better  performance  by  n iive  programmers.  Figure  3 illus- 
trates the  format  of  Miller’s  procedure  table.  It  is  very  similar  to 
(and  in  fact  partially  derived  from)  production  systems.  Due  to  tie 
simple  control  structure  of  production  systems,  especially  of  the  LHS 
scan  type,  we  can  imagine  the  following  type  of  instructions  being 
nearly  sufficient  to  introduce  a user  to  the  operation  of  his  terminal: 


i 


This  terminal  operates  according  to  a set  of 
r«»les.  Whenever  it  finds  a rule  that  is  true, 
it  applies  that  rule.  If  you  want  to  know  why 
it  is  asking  you  for  some  item  of  information, 
or  why  it  took  some  action,  type  "?"  and  it 
will  show  you  the  rules  it  followed  in  taking 
that  action. 


If,  in  addition,  the  rules  themselves  are  in  simple  English  so  that 
they  are  directly  readable  by  a user,  tho”  believe  he  will  find  the 
operation  of  this  device  quite  understandable.  Although  the  user  will 
of  course  not  understand  all  the  nuarces  of  its  operation,  he  is  at 
least  not  bewilderea  at  the  start,  and  can  add  incrementally  to  his 
understanding  with  experience.  The  user  must  realize,  however,  during 
this  initial  introduction  to  the  system  that  there  are  nuances  and  that 
he  should  not  be  overly  complacent  or  trusting  of  system  behavior. 

A RHS  scan  backward-chaining  system,  although  more  complex  in  its 
control  structure,  can  give  rational  explanations  of  its  behavior  in  a 
manner  that  makes  the  flow  of  control  among  rules  understandable. 

Again,  we  offer  the  use  of  MYCIN  by  computer-naive  physicians  as  proof 
for  this  assertion. 

3.  Incremental  addition  of  knowledge . With  proper  design,  pro- 
duction systems  can  allow  gradual,  incremental  addition  of  knowledge 
and  heuristics  in  a top-down  manner.  If  the  set  of  rules  is  unordered, 
as  is  usually  the  case  in  a RHS  scan  system  and  could  be  the  case  in 
a LHS  sc^n  inode,  then  new  rules  can  be  added  to  the  set  without  concern 
for  their  placement.  Tf  the  mode  of  operation  is  LHS  scan  through  an 


Procedure  Table 


Label  - 


Question 


Action(s) 


Any  card  in  input 
box? 


Look  at  next 
card 


Go  To 


No:  Stop 


Name  on  card  has 
second  letter  as 
"Not-L"  or  last 
letter  as  "N" 


Put  card  in  box 
ir 3,  increase 
Counter  1 


At 


> 


Put  card  in 
Box  // 2 


Problem:  Put  a card  in  Box  3 if  either  the  name 

on  the  card  has  the  second  letter  not  "L" 
or  else  the  last  letter  is  "N"  (or  both). 

Count  the  number  of  cards  in  Box  3 using 
Counter  1.  Put  the  remaining  cards  in  Box  2. 


Fig.  3 — Format  of  Miller's  decision  table, 
with  associated  problem  description 
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ordered  set  of  rules  (choosing  the  first  true  one  encountered),  then  the 
location  of  rules  to  be  added  within  that  ordered  set  becomes  important. 
For  these  reasons,  we  believe  that  unordered  rule  sets  should  be  used 
to  implement  at  least  those  portions  of  intelligent  terminal  agents 
whicl  are  expected  to  be  modified  to  any  degree  by  the  user. 

An  example  of  the  operation  of  the  MYCIN  system  shows  the  incre- 
mental addition  of  knowledge.  When  a predicate  on  the  LHS  of  some  rule 
in  the  MYCIN  system  needs  an  item  of  information,  it  searches  for  rules 
whose  RHS  assign  that  datum.  If  such  rules  are  found,  their  evaluation 
is  attempted.  If  there  are  no  such  rules,  the  system  requests  that 
datum  from  the  user.  This  provides  a natural  opportunity  for  the  grad- 
ual introduction  of  knowledge  and  heuristics  to  the  system.  If  the 
user  does  not  wish  to  continue  supplying  that  datum  to  the  system,  he 
has  the  option  of  giving  the  system  a rule  describing  how  to  derive 
that  datum  from  other  data  within  the  data  base.  In  conjunction  with 
this  new  rule,  it  might  be  appropriate  for  the  user  to  give  the  system 
other  additional  rules  for  acquiring  information  from  external  sources. 
In  this  manner,  gradual  evolution  of  the  behavior  of  the  system  takes 
place  to  meet  the  needs  of  the  user  in  his  possibly  unique  environment. 

4.  Trainahility  and  learning.  Assume  production  rules  are  stated 
in  a constrained  syntax  so  that  their  meaning  Is  understandable  by 
machines,  and  that  each  rule  is  a "noninteracting  chunk  of  knowledge 
or  behavior."  Then  it  becomes  possible  for  a computer  program  to  create 
rules  in  the  proper  format  and  insert  them  into  existing  sets  of  rules 
to  change  the  behavior  of  a production  system.  It  might  also  modify 
existing  rules  to  change  a system's  behavior . 

Waterman  [1970]  hat  discussed  the  creation  of  new  rules  from  train- 
ing information  and  the  process  of  "blending"  new  rules  into  an  ordered 
set  of  existing  rules.  He  has  placed  the  trairing  information  a sys- 
tem should  receive  (or  extract)  from  a user  into  three  categories: 

a.  Acceptability  information:  an  acceptable  decision  for 

a particular  situation. 

b.  Relevancy  information:  the  situation  elements  relevant 

to  making  this  acceptable  decision. 
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c.  Justification  information:  the  reason  the  decision  is 

being  made,  expressed  as  an  evaluation  of  these  rele- 
vant situation  elements. 

The  relevancy  and  justification  information  is  used  to  create  the  pat- 
tern part  (LHS)  of  a new  rul®,  and  the  acceptability  information  is 
used  to  create  the  action  part  (RHS)  of  the  new  rule.  The  newly  created 
rule  is  called  a training  rule.  Waterman  gives  an  algorithm  for  decid- 
ing whether  to  "blend”  the  training  rule  into  an  existing  ordered  set 
of  rules  by  using  it  to  modify  an  existing  rule  or  by  adding  it  to  the 
existing  set  in  an  appropriate  location. 

In  a recent  paper,  Waterman  [1974]  discusses  several  examples  of 
adaptive  production  systems,  written  in  the  PAS-II  notation  [Waterman 
1973] , in  which  all  adaptivity  is  obtained  by  adding  new  rules  to  ex- 
isting ordered  rule  sets,  and  training  information  ie  generated  inter- 
nally rather  than  requiring  feedback  frcra  a user. 

5.  Unified J consistent  structure.  If  a production  system  is  con- 
sidered as  a programming  language,  it  is  one  with  only  a single  state- 
ment type:  a pattern-action  rule.  If,  as  we  expect,  it  is  as  easy  to 

program  and  update  intelligent  terminal  agents  in  production  systems 
as  it  is  in  ordinary  high-level  programming  languages,  then  for  this 
application  production  systems  satisfy  Occam's  Razor:  they  are  the 

simpler  form. 

In  addition,  it  is  possible  co  program  significant  portions  of  the 
monitor  (e.g.,  the  conflict  resolution  strategy)  in  a production  sys- 
tem form,  so  chat  the  structure  of  the  entire  system  becomes  more  uni- 
fied; in  that  case,  the  monitor  itself  becomes  amenable  to  modifica- 
tion, and  possibly  to  adaptive  learning. 

There  are  also  some  disadvantages  in  the  use  of  production  systems. 
The  two  major  ones  are: 

1.  It  can  be  difficult  to  code  an  operation  in  the  form  of  a 
production  system,  particularly  for  goal-oriented  rule  sets.  Consider- 
able thought  must  be  given  to  the  choice  of  objects,  attributes,  and 
values  by  which  a problem  area  is  represented.  (However,  the  problem 
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of  choosing  a good  data  representation  is  :ert  inly  not  unique  to 
production  systems;  the  problem  lies  more  tn  trying  to  fit  all  appli- 
cations into  this  particular  procrustean  bud.)  One  must  also  carefully 
choose  certain  attributes  uf  objects  to  represent  "state  variables" 
which  encode  the  state  of  a computation  oi  deduction.  The  values  of 
these,  state  variables  are  tested  by  varicjs  rules  to  trigger  their 
potential  applicability.  In  this  manne-  production  systems  encode 
explicitly  that  which  in  ordinary  high-level  programming  languages  is 
implicit  in  the  nesting  of  control  s.itements.  For  example,  a tradi- 
tional programming  language  nested  control  structure  such  as; 

if  A then 

if  B then  C 

else  if  J then  E;  else; 
else  G; 

might  be  encoded  in  ? production  system  in  the  following  manner: 
if  A then  state_l; 

if  F<:ate_l  and  B then  C; 

if  state  1 and  not  B then  state_2; 
if  state  2 and  D then  E; 
if  not  A then  G: 

Sum  explicitness  in  a production  system  allows  the  desired  relative 

c tonomy  of  individual  rule^,  but  at  the  price  of  requiring  the  pro- 

grammer to  create  names  for  many  intermediate  states  'f  his  process. 

In  the  RITA  system,  we  hope  to  oveicome  this  disadvantage  by 
having  system  experts  create  initial  systems  anil  user  agents  having 
general  applicability.  Individual  users  are  expected,  at  least  ini- 
tially, to  make  only  rather  minor  modifications  and  e*  .ncements  to 
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the  basic  system.  Therefore,  the  vocabulary  and  overall  design  of  a 
user  agent  will.be  established,  providing  many  guidelines  and  examples 
for  the  individual  user. 

2.  Production  systems  are  often  inefficient.  It  is  quite  easy 
to  design  systems  in  which  the  pattern  parts  of  hundreds  of  rules  are 
tested  against  the  data  base  before  a successful  match  is  found;  It  Is 
also  easy  in  goal-oriented  systems  to  pursue  lengthy  chains  ul  reason- 
ing which  are  not  useful.  The  same  deductions  may  be  recomputed  re- 
dundantly many  times  in  separate  logic  paths,  without  awareness  in  the 
cystem  of  the  duplication  of  effort. 

Our  design  of  the  RITA  system  has  not  been  significantly  influenced 
by  efficiency  considerations.  The  simple  user  agents  which  have  been 
constructed  to  date  (e.g.,  for  handling  File  Transfer  Protocol  inter- 
actions on  the  ARPANET)  have  required  only  30  to  40  rules  and  are  not 
inefficient.  As  more  complex  agents  are  constructed,  we  believe  there 
arc  a number  of  monitor  enhancements  that  can  be  designed  to  increase 
efficiency  (e.g.,  through  hash-coded  lookup  tables  to  aid  in  finding 
applicable  rules)  which  can  be  added  as  the  need  arises.  A system 
'-ailed  PSH,  currently  under  development  within  the  Computer  Science  De- 
partment at  Carnegie-Mellon  University,  is  a testbed  for  a major  study 
of  methods  of  obtaining  efficiency  in  production  systems. 

With  the  above  advantages  and  disadvantages  in  mind,  and  given 
the  options  available  in  production  system  design  and  the  design  re- 
quirements derived  from  the  particular  application  under  discussion, 
we  can  now  discuss  the  design  decisions  made  to  daLe  in  the  implementa- 
tion of  the  RITA  system. 

DESIGN  DECISIONS  IN  THE  RITA  SYSTEM  IMPLEMENTATION 

Our  design  decisions  in  creating  a production  system  for  our  par- 
ticular needs  are  discussed  under  four  headings:  data  base,  rules, 

monitor,  and  system  architecture. 

Data  Base 

The  data  base  upon  which  RITA  rules  operate  is  called  a context ; 
it  consists  of  an  unordered  set  of  objects.  Each  object  has  a name, 


or  type,  and  there  can  be  more  thin  one  object  in  the  context  of  the 
same  type.  There  is  neither  an  external  structure  imposed  on  the  set 
of  objects  in  the  context  nor  a requirement  that  each  object  have  a 
unique  identifier  associated  with  it.  Each  object  can  have  one  or 
more  named  attributes,  and  all  attributes  attached  to  an  object  must 
have  names  which  are  mutually  distinct.  Each  attribute  has  an  as- 
sociated value,  which  is  either  a character  curing  or  a set  of  values. 

Objects,  attributes,  and  values  may  be  created  or  deleted  dynam- 
ically by  the  actions  of  rules.  If  an  attribute  being  tested  by  a 
rule’s  LHS  predicate  does  not  exist,  it  is  considered  to  be  "not  known." 
It  is  possible  by  a rule  action  (except  within  a goal-oriented  monitor) 
to  reset  an  attribute  having  a value  back  to  the  "not  known"  status. 
Goal-oriented  monitors  may  not  reset  the  vc^ue  of  any  attribute;  they 
may  only  set  values  which  were  previously  not  known.  This  restriction 
is  necessary  to  preserve  the  integrity  of  information  upon  which  chains 
of  logica1  reasoning  are  based. 

Vs  an  option,  it  is  possible  to  attach  a "level  of  certainty"  to 
a scalar  attribute  value  as  it  is  being  set.  In  this  case,  an  attribute 
can  have  several  different  values  associated  with  it,  each  with  a dif- 
ferent level  of  certainty.  Levels  of  certainty  attached  to  values  are 
adjusted  as  additional  positive  or  negative  certainty  factors  for  those 
values  are  asserted  by  the  action  of  rules.  Our  planned  use  of  cer- 
tainty factors  has  been  strongly  influenced  by  their  implementation 
in  the  MYCIN  system.  Our  implementation  is  expected  to  differ  in  some 
details,  but  a discussion  of  those  differences  will  not  be  presented 
here. 

Figure  4 concains  examples  o'  object  types  aid  associated  attri- 
bute names  and  values  which  mighv  be  used  in  a user  agent  within  the 
RITA  system. 

The  data  structure  we  have  chosen  is  not  the  most  general  one 
possible.  (An  obvious  extension  allowing  much  more  generality  would 
be  to  allow  references,  or  pointers,  to  objects  as  attribute  values. 

As  mentioned  earlier,  this  would  give  the  capability  for  arbitrarily 
named  relations  among  objects.)  As  with  other  i/nplementation  deci- 
sions, we  have  chosen  what  we  consider  to  be  the  simplest  format  and 
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object  type 

attribute  name 

sample  value 

file 

name 

"foo.baz" 

directory 

"jjg" 

site  id 

"rand-isd" 

size 

20000 

owners  _nanie 

"gillogly " 

site 

id 

"rand-llM 

operating  system  name 

"unix" 

machine_type 

"pdp-ll/A5" 

guest  account  name 

"netgues t" 

guest  accour.t_password 

"netguest" 

known-user-se t 

("jjg”,  "rha’\ 
"tsg") 

known  j>erson 

name 

"gillogly" 

primary  si te_id 

"rand-isd" 

primary_directory 

"JJg" 

primary_pas sword 

"whumpus" 

secondary_site_ id 

"cmu-lOa" 

i 

secondary _s it  e_di rectory 

"g250al2" 

1 

L_ 

secondary  site  password 

"foo" 

Fig. 

4--Examples  of  RITA  object 
attributes,  and  values 

types, 
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conceptual  structure  which  allows  the  description  of  situations  and 
heuristics  related  to  intelligent  terminal  agents.  With  mere  experi- 
ence in  using  the  RITA  system,  some  of  these  decisions  are  almost  cer- 
tain to  change. 

Rules 

RITA  rules  are  expressed  in  a finite  syntax  (technically,  parsafe 
by  an  LR(i)  algorithm) . A complete  syntax  chart  for  RITA  rules  as 
they  now  stand  is  given  In  a companion  document  ['nderson  and  Ctllogly, 
to  be  published].  We  have  chosen  a syntax  patterned  after  the  general 
English  output  form  generated  to  display  MYCIN  rules  to  a user.  We 
believe  that  this  syntax  is  simple  enough  to  be  read  and  written  by  a 
computer-naive  user.  Figure  5 contains  several  examples  of  clauses 
which  can  be  used  in  RITA  rules;  more  complete  examples  are  contained 
in  the.  appendix. 

Such  facilities  au  string-manipulation  are  provided  in  the  RITA 
system  by  a set  of  primitive  functions  which  may  be  called  in  the  pre- 
dicates or  actions  of  rules. 

We  note  that  all  RITA  rules,  including  those  to  be  interpreted  by 
a goal  oriented  monitor,  are  expressed  in  the  same  syntax.  MYCIN,  on 
the  other  hand,  uses  a goal  rule  hand-coded  In  LISP  which  does  not 
follow  normal  M.JIN  conventions. 

We  have  decided,  for  simplicity,  not  to  implement  multiple  rule 
sets  which  limit  the  applicability  of  a rule  to  those  times  when  its 
set  is  the  "current  state"  of  the  system.  1’rom  our  experience  to  date 
with  the  system,  the  additional  mechanisms  required  for  explicit  trans- 
fer of  control  among  named  rule  sets  does  not  seem  justified  by  ad- 
vantages in  operating  efficiency. 

Monitors 

We  have  found  that  different  types  of  monitors  are  necessary  for 
various  specific  tasks  and  situations,  and  that  no  one  monitor  type  is 
sufficient,  for  our  purposes.  For  example,  interactions  with  an  ex- 
ternal information  system  to  handle  routine  protocols  are  best  handled 
by  a LHS  scan  monitor,  acting  in  what  might  be  called  a "stimulus- 
response"  mode.  On  the  other  hand,  ' is  sometimes  necessary  for  an 
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Lef t -hand -side  predicate  clauses 

IF:  the  name  of  rhe  system  is  "unix" 

IF:  the  name  of  the  system  is  the  name  of  the 
desired__system 

IF:  the  n^e  of  the  system  is  not  known 

IF:  there  is  a response  v’  ose  arrival_time  is  less  than 

the  max_expected_ delay  of  the  system 

Right-hand-side  action  clauses 

THEN:  set  the  name  of  the  system  to  "net  access  program" 

THEN:  set  the  val^d_jLd_set  of  the  remote_site  to  the 

id  of  every  site  whose  id  is  known 

THEN:  deduce  the  guest_account__name  of  the  remote_site 

THEN:  create  a remote_site  whose  id  is  "cmu-lOa" 

THEN:  receive  the  next  line  from  the  system_JO_jpipe 

as  the  value  of  the  response 

THEN:  6end  "Which  rule  do  you  wish  to  see"  to  the  user 

THEN:  return  success 


Fig.  5 — Examples  of  RITA  rule  clauses 
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intelligent  terminal  agent  to  make  deductions  (e.g.,  about  the  n»st 
likely  site  on  the  ARPANET  for  a particular  person  to  have  a mailbox, 
given  that  person's  attributes).  Deductions  are  best  made  by  a THIS 
scan,  goal-driven  monitor. 

Consequently,  we  have  implemented  several  different  monitors: 

o LHS  scan,  with  ordered  rule  set 

o Lh:>  scan,  with  unordered  rule  set 

o RRS  scan  with  backward -chaining  (implicitly,  a rule  set  is 
treated  as  unordered) 

Nothing  in  our  implementation  precludes  the  development  of  other  moni- 
tors if  the  need  arises.  The  top-level  monitor  in  a user  agent  will 
use  a LHS  scan  with  an  unordered  rule  set;  however,  it  is  possible  for 
the  following  action  clause  of  some  rule  to  be  executed: 

DEDUCE  attribute  OF  object. 

This  clause  triggers  the  operation  of  the  RHS  scan  backward-chaining 
monitor  with  the  goal  of  deducing  the  value  of  the  named  attribute. 
Only  rules  in  the  system  which  are  designated  as  RHS  scan  rules  are 
used  during  the  backward-chaining  process  to  deduce  the  required  in- 
formation. Upon  completion  of  a deduction,  control  reverts  to  the 
action  clause  of  the  LHS  scan  rule  following  the  DEDUCE  clause,  or  if 
there  are  none,  to  the  next  applicable  rule  chosen  by  the  LHS  scan 
monitor.  It  is  not  possible  to  explicitly  invoke  an  LHS  scan  monitor 
during  a goal-directed  deductive  operation. 

The  design  of  a goal-oriented  backward-chaining  monitor  involves 
many  unique  decisions  not  encountered  in  LHS-driven  monitors.  An  men- 
tioned earlier,  our  goal-directed  monitor  has  been  heavily  influenced 
by  MYCIN,  but  differs  from  that  of  MYCIN  primarily  in  the  following 
respects: 


1.  In  pursuing  a goal  without  specified  levels  of  certainty  in 
rules,  our  search  terminates  when  the  desired  information  is  first 
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found  (rather  than  pursuing  all  possible  paths,  as  in  MYCIN,  before  com- 
bining the  certainty  factors  associated  with  all  results  found) . 

2.  The  binding  of  objects  and  attributes  mentioned  in  rules  to 
objects  in  the  data  base  is  governed  in  MYCIN  by  a data  hierarchy.  The 
data  mentioned  in  a rule  are  bound  to  a datum  at  a level  in  that  hier- 
archy dependent  on  the  "lowest"  object  mentioned  in  the  rule.  From 
that  binding,  a context  is  inherited  from  the  hierarchy  which  can  re- 
solve many  possible  ambiguities  and  search  requirements.  In  RITA,  on 
the  other  hand,  our  data  context  Is  not  structured.  Consequently,  no 
implied  context  is  used  to  resolve  searches. 

3.  In  MYCIN,  an  automatic  search  is  performed  to  fill  in  certain 
values  of  attributes  of  a newly  created  object.  In  RITA,  values  of 
attributes  are  searched  for  only  if  needed  to  satisfy  a subgoal. 

4.  RITA  and  MYCIN  both  have  a type  of  LHS  predicate  clause  which 
acts  like  an  existential  quantifier: 

IF:  there  is  a block  whose  color  is  blue  ... 

The  RITA  system  performs  a complete  backtracking  scan  in  an  attempt  to 
satisfy  nested  t .istentials.  Ultimately,  if  necessary,  all  possible 
relevant  data  bindings  will  be  attempted  to  satisfy  a set  of  conditionals. 
MYCIN  does  not  perform  such  backtracking  under  similar  conditions. 

System  Architecture 

Our  implementation  of  R.ITA  has  been  influenced  by  the  factors 
mentioned  in  Sec.  II:  funding  source,  expected  user  community,  and 

available  computing  resources.  In  this  context,  we  have  made  the 
following  implementation  decisions  in  designing  the  software  architec- 
ture of  the  RITA  system: 

1.  For  efficient  operation  on  the  limited  resources  of  a mini- 
computer, we  have  decided  to  "compile"  English-like  rule  and  object 
descriptions  into  an  internal  list-structure  form  for  use  ly  the  moni- 
tor; however,  corresponding  "decompilers"  allow  a user,  upon  request, 
to  see  any  data  in  the  symbolic,  English-like  form.  Rules  and  object 
descriptions  are  always  stored  externally  (e.g.,  on  disk)  in  their 
English-like  form. 
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2.  RITA  has  been  designed  as  two  cooperating  modules,  so  that 
only  the  currently  active  module  need  reside  in  the  core  during  the 
operation  of  a user  agent*  Such  modularity  is  aided  by  the  facilities 
in  the  UNIX  operating  system  for  communication  between  separate  pro- 
cesses. 

The  user  interface  module  gives  the  user  one  or  more  windows  within 
which  text  can  be  displayed,  with  the  facilities  of  the  Rand  Editor 
available  for  text  manipulation  within  those  windows.  It  allows  crea- 
tion of  rule  sets  and  contexts  in  a symbolic  English-like  form,  and 
passes  rules  and  commands  to  the  monitor  to  allow  user  control  over 
its  operation. 

The  monitor  module  contains  facilities  for  compiling  symbolic 
form  rules  and  data  descriptions  into  an  internal  list-structure  form 
and  for  decompiling  internal  forms  back  into  symbolic  form  upon  request. 
It  uses  one  of  the  available  monitors  to  apply  a rule  set  to  a context, 
and  emits  trace  information  to  a history  file  for  use  by  diagnostic 
and  tutorial  facilities. 

3.  We  have  chosen  to  use  an  excellent  compiler-compiler,  named 
YACC  (Yet  Another  Compiler-Compiler)  and  available  on  the  UNIX  system, 
to  implement  our  rule  and  object  compilers.  Since  all  compilation  of 
symbolic  lurms  of  rules  and  objects  is  governed  by  a BNF  grammar,  it 
is  not  difficult  to  make  changes  in  the  surface  syntax  of  rule  and  ob- 
ject descriptions. 

A basic  form  of  RITA  is  currently  operational.  The  following 
section  gives  brief  descriptions  of  the  features  cwu.*ant.ly  implemented 
in  RITA,  enhancements  planned  during  the  next  six  to  nine  months,  and 
research  questions  raised  by  our  work  to  date. 
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V.  CURRENT  PROGRAM  STATUS  AND  CONCLUDING  REMARKS 

The  following  features  are  Implemented  in  the  current  (January 
1976)  version  of  RITA: 

Both  pattern-directed  and  backward-chaining  monitor  *x>des  operate 
with  unordered  rule  sets,  with  the  backward-chaining  mode  capable  of 
being  initiated  by  the  pattern-directed  mode. 

The  user  can  initiate,  interrupt,  resume,  and  terminate  the  monitor’s 
operation.  During  an  interruption,  he  may  add,  modify,  or  delete  rules 
or  objects,  inspect  rules  or  objects,  and  set  conditions  [e.g.,  the 
testing  of  a particular  rule's  predicates  or  execution  of  its  actions) 
upon  which  monitor  operation  should  be  interrupted.  He  may  also  obtain 
information  about  the  recent  history  of  the  monitor's  operation,  such 
as  which  rules  have  been  tested  and  have  failed  or  succeeded,  or  which 
object's  attribute  values  have  been  set. 

Attribute  values  may  be  primitive  values  (e.g. , character  strings) 
or  sets  of  values.  Members  of  such  value  sets  may  themselves  be  sets, 
permitting  an  arbitrarily  deep  nesting  of  value  data. 

The  RITA  system  can  irteract  with  external  information  systems, 
either  via  the  ARPANET  or  dial-up  access  over  telephone  lines. 

RITA  agents  may  be  initiated  by  a reminder  facility  added  by  Rand 
a 

to  the  UNIX  system.  Agents  may  be  "reminded"  to  start  operation  at 
a specific  time  and  date  (e.g.,  at  3 a.m.  on  March  17,  1976)  or  at  a 
relative  time  ^e.g.,  six  hours  from  now,  or  in  three  days).  These 
facilities  can  also  be  used  to  awaken  agents  on  a regular  periodic 
schedule  (e.g.,  every  day  at  3 a.m.).  The  remind  function  allows  agents 
to  periodically  check  the  status  of  a lengthy  remote  operation  or  to 
initiate  routine  tasks  aft^r  normal  working  hours.  Reminders,  when 
created,  are  written  on  a special  disk  file  along  with  such  status  in- 
formation as  whether  they  are  pending  or  in  operation  and  the  time  and 


The  remind  function,  which  performs  very  useful  functions  both 
for  RITA  and  UNIX  system  users,  was  conceived,  designed,  and  implemented 
by  Dr.  Steven  Zucker  of  the  Rand  computer  research  staff. 
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date  for  initiation.  Whenever  the  UNIX  system  is  restarted,  for  example 
after  a power  shut-down  for  maintenance  or  a system  crash,  a system 
function  automatically  checks  the  reminder  file  for  pending  actions. 

In  this  way,  RITA  agents  are  usually  capable  of  operating  in  pursuit  of 
goals  over  extended  periods  of  time  in  spite  of  interruptions.  (An 
exception  is  when  RITA  is  interrupted  while  interacting  with  external 
systems.  It  is  often  not  possible  to  resume  an  interaction  with  an 
external  system  at  some  midpoint  in  that  interaction.) 

Principal  features  discussed  in  this  report  but  not  yet  operational 
within  the  RITA  system  are 

o The  ability  to  use  levels  of  confidence  on  attribute  values  and 

o The  use  of  the  Rand  Editor  as  part  of  a user's  interface  to 

RITA  for  the  creation,  modification,  and  perusal  of  rules  and 
objects  in  a user  agent. 

These  capabilities  are  expected  to  become  available  within  several 
months  after  the  publication  of  this  report. 

The  RITA  interpreter  module  currently  occupies  a total  of  about 
49,000  bytes  of  core  (28,000  program  and  21,000  data).  The  user  inter- 
face module  is  quite  small  (about  9000  bytes)  . The  two  modules  can 
grow  independently  to  the  maximum  core  available.  In  addition,  about 

250  bytes  are  required  per  rule  stored,  plus  100  bytes  per  object 
* 

stored.  Therefore,  our  current  system,  with  64,000  bytes  each  of 
program  and  data  storage  space  available,  can  grow  about  220  percent 
in  program  size  and  can  store  in-core  an  agent  consisting  of  (for  ex- 
ample) 120  rules  operating  upon  a data  base  having  130  objects. 

User  agents  comprising  about  50  rules  are  now  in  use,  and  can, 
for  example,  handle  ARPANET  file  transfer  operations.  We  expect  to 
create  agents  at  least  several  times  this  size  in  the  near  future. 

Many  questions  are  still  unanswered  at  this  stage  of  the  research 
project.  For  example: 

* 

Assuming  about  5 clauses  per  rule  and  10  attributes  per  object. 
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o Will  a computer-naive  user  really  be  able  to  modify  the  opera- 
tion of  a user  agent  by  adding  or  modifying  rules?  li  so,  how 
long  a prior  familiarization  period  is  required? 
o At  what  level  of  size  or  complexity  of  a user  agent  will  speed 
of  operation  and  efficiency  become  important  considerations? 
o What  about  system  security?  Knowledge  about  passwords,  access 
keys,  data  formats,  and  account  numbers  for  external  systems 
might  well  reside  within  RITA  user  agents,  making  the  intelli- 
gent terminal  itself  a valuable  target  for  compromise.  Even 
with  physical  security,  such  as  restricting  access  to  the  room 
containing  the  terminal,  often  there  will  still  remain  external 
communication  paths  to  the  machine  that  allow  possible  access 
to  data.  We  need  to  understand  more  about  the  constraints  which 
must  be  placed  on  access  to  intelligent  terminals  containing 
sensitive  data  in  representative  user  environments. 

In  conclusion,  we  emphasize  that  this  is  a report  on  work  in  prog- 
ress, and  many  questions  are  left  unanswered.  However,  we  are  encouraged 
by  our  initial  experimentation  in  the  use  of  production  systems  to  rep- 
resent heuristics  governing  intelligent  terminal  behavior.  Their 
ability  to  provide  explanations  of  that  behavior,  to  be  modified  and 
incrementally  extended  by  a user,  and  to  operate  in  either  a pattern- 
directed  or  goal-directed  manner  are  all  potentially  valuable  features. 

We  believe  the  RITA  system,  whose  design  we  have  discussed  here,  pro- 
vides a good  testbed  for  the  demonstration  and  evaluation  of  these  in- 
telligent terminal  agent  capabilities. 


. . 
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Appendix 

EXAMPLES  OF  RITA  OPERATION 


LHS  SCAN  OF  UNORDERED  RULE  SET 

As  an  illustration  of  an  unordered  rule  set  to  be  interpreted  by 
a LHS  scan  monitor,  consider  the  following  set  of  eight  rules.  The 
purpose  of  these  rules  is  to  generate  a telephone  call  to  the  recipient 
and  to  notify  the  user  when  the  call  has  been  successfully  placed.  The 
rules  must  deal  with  such  exigencies  of  the  telephone  system  as  busy 
signals  and  no  answar.  These  rules  assume  the  context  contains  an 
object  called  a "recipient",  who  has  the  following  attributes: 


)bject  Type 

Attribute  Name 

Example  Value 

Comment 

recipient 

name 

"Bob  Jones" 

pr  J mary__phone// 

"(213)  393-0411" 

alternate_phone// 

"(213)  393-0412" 

[optional] 

home_phons// 

"(714)  454-8812" 

[optional] 

[optional]  means  that  the  attribute  need  not  exist  for  the  recipient. 

The  rules  create  an  object  of  type  "call"  whose  attributes  record 
the  current  knowledge  about  the  attempted  call.  This  object  is  in 
turn  used  by  another  group  of  rules  which  specializes  in  dealing  with 
the  external  telephone  system  through  a dialing  unit,  and  which  sets 
a "status"  attribute  for  the  call  to  reflect  the  information  reported 
by  the  dialing  mit. . The  "call"  object  has  the  following  attributes 
and  sample  values : 


Object  Type  Attribute  Name 


Sample  Values 


call 


status 


target 

desired_placement_time 

priority 


"to  be  initiated" 
"busy" 

"answered" 

"not  answered" 
"unacceptable  phone//’’ 

"primary  phone#" 
"alternate  phone//" 
"home  phone#" 

"75/7/20  1800" 

"normal" 

"urgent" 
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The  rule  set  is  shown  below;  comments  are  enclosed  in  square  brackets. 
The  particular  syntax  used  to  state  the  rules  is  indicative  of  the 
form  of  RITA  rules,  but  is  subject  to  change.  The  reference  manual 
[Anderson  and  Gillogly,  to  be  published]  should  be  consulted  for  the 
current  formal  description  of  allowable  RITA  rule  forms. 

[RULES  FOR  PLACING  A TELEPHONE  CALL] 


RULE  1 [when  to  create  a new  call] 

IF:  there  is  a recipient  whose  primary_phone#  is  known  & 

there  is  not  a call 

THEN:  create  a call  whose  status  is  "to  be  initiated"  & 

whose  target  is  "primary  phone#"  & + 

whose  desired_j)lacement_time  is  currenttime ; ' 


RULE  2 


[when  to  actually  dial  the  number] 


IF:  the  status  of  the  call  is  "to  be  initiated"  & 

the  desired_j>lacement_time  of  the  call  is  less  than 
[i.e.  earlier  than]  currenttime 

THEN:  set  the  status  of  the  call  to  "ready  for  dialing"/ 


RULE  3 


[what  to  do  with  a busy  signal] 


IF:  the  status  of  the  call  is  "busy" 


THEN: 


set  the  desired  placement _time  of  the  ca1  to 
current. time  + 2 [minu'  .s]  & 
set  the  status  of  the  call  to  "to  be  i .tiated"; 


We  assume  "currenttime"  is  a function  \i  ich  returns  the  current 
date/time  as  its  value. 

*We  assume  this  call  status  triggers  dditional  rules,  not  shown 
here,  which  interact  with  a dialing  unit  .o  physically  dial  a call, 
then  read  the  dialing  unit1 8 output  sigv  ils  and  set  the  "status"  at- 
tribute of  the  call  to  one  of:  "busy"  "answered",  "not  answered", 

"unacceptable  phone#".  These  other  r les  are  expected  to  use  the 
"target"  attribute  of  the  call  to  select  a phone#  from  one  of  the  at- 
tributes of  the  recipient. 

We  use  infix  notation  (e.£,,  "a+b")  in  these  rules  to  express 
arithmetic  operations  in  an  eas'  i.y  readable  form,  although  the  current 
version  of  RITA  requires  the  u/a  of  functional  notation  (e.g., 
"plu3(a,b)") . 


RUL 1 4 


[what  to  do  if  the  ~:.il  is  answered] 


IF:  the  status  of  the  call  is  "answered" 

THEN:  send  concat  (the  name  of  the  recipient, 

"has  been  reached  at  his/her", 
target  of  the  call, 

".  Please  pick  up  your  phone.")  to  the  user  & 
delete  the  call;* 


RULE  5 [what  to  do  if  primary  phone//  is  not  answered] 

IF:  the  status  cf  the  call  is  "not  answered"  & 

the  target  of  the  call  is  "primary  phone//"  & 
the  alternate_phone#  of  the  recipient  is  known 

THEN:  set  the  target  of  the  call  to  "alternate  phone#" 

set  the  status  of  the  call  to  "to  be  initiated"; 


RULE  6 [what  to  do  if  alternate  phone#  is  not  answered] 

IF:  the  status  of  the  call  is  "not  answered"  & 

the  target  of  the  cr.li  Is  "alternate  phone#"  & 
the  priority  of  the  call  is  "normal" 

THEN:  set  the  desired_placement_tlme  of  the  call  to 

cur rent time  + 30  [minutes]  & 
set  the  target  of  the  call  to  "primary  phone#"  & 
set  the  status  of  the  call  to  "to  be  initiated"; 


RULE  7 [special  rule  for  an  unanswered  urgent  call] 

IF:  the  status  of  the  call  is  "not  answered"  & 

the  target  of  the  cill  is  "alternate  phone#"  & 
the  priority  of  the  call  is  "urgent"  & 
the  home_phone#  of  the  recipient  is  known 

THEN:  set  the  target  of  the  call  to  "home  phone//"  & 

set  the  status  of  the  call  to  "to  be  initiated"; 


This  rule  assumes  the  existence  of  a "concat"  function  which 
evaluates  its  arguments,  then  returns  a single  character  string  con- 
sisting of  the  concatenation  of  the  argument  values. 


t i - 1 ■ -if  r ri 


-38- 


RfJLE  8 [what  to  do  with  an  unanswered  home  call] 

IF:  the  status  of  the  call  is  "not  answered"  & 
the  target  of  the  call  is  "home  phone//" 

THEN:  set  the  desired__placement_time  of  the  call  to 

current time  + 15  [minutes]  & 
set  the  status  of  the  call  to  "to  be  initiated"; 

The  above  rules  illustrate  a fragment  of  a complete  system  for  inter- 
acting with  the  telephone  system.  As  such,  they  assume  a considerable 
amount  of  context  and  leave  several  questions  unanswered;  for  example: 
These  rules  assume  the  person  who  places  the  call  will  be  avail- 
able to  handle  the  call,  either  now  or  at  some  arbitrary  time  in  the 
future  when  the  call  becomes  completed.  If  this  is  unrealistic,  Rule 
2 should  check  for  the  availability  of  the  caller  before  actually  dial- 
og the  call. 

The  rules  for  determining  the  priority  of  the  call  are  not  shown. 
Presumably,  they  would  encode  a heuristic  like  "assume  it's  normal  un- 
less I tell  you  explicitly  that  it’s  urgent." 

Ihtse  rules  might  be  considerably  enhanced  by  the  addition  of  other 

rules  to  determine,  given  the  area  code  of  the  target  phone  number, 

* 

the  time  zone  of  the  recipient;  it  could  then  be  determined  whether 
curienttime  in  that  zone  is  within  scheduled  business  hours,  during 
the  lunch  hour,  or  outside  scheduled  business  hours. 

This  information  could  then  be  used  to  influence  the  calling  strategy 
in  such  situations  as  an  unanswered  call. 

As  an  illustration  of  the  relative  ease  of  modifying  and  extend- 
ing an  existing  rule  set,  suppose  that  during  repeated  use  of  the 
above  agent  a user  notices  a possible  flaw  in  the  logic:  recipient 
Steve  Kramer  does  not  have  an  alternate  phone  number,  but  he  does  have 
a known  home  phone  number.  An  urgent  call  is  placed  to  Steve,  who 
does  not  answer  his  primary  number.  No  further  attempt  to  place  the 


He  use  this  logic  for  simplicity  in  this  illus-.ration.  In  prac- 
tice, some  area  code  zones  cross  time  zone  boundaries,  so  more  complex 
logic  is  needed. 


.r, ..  . 


iuiirirhril'ft«rfrnr-iiiiffrTii^rrm~-~i  rr ■ 


-39- 


call  is  made  by  the  agent;  in  particular,  his  home  number  is  not  tried. 
By  observing  the  rules  used  to  arrive  at  this  decision,  the  user  re- 
alizes that  Rule  7 only  sets  the  target  of  the  call  to  the  home  number 
if  the  alternate  number  is  unansvrered.  He  decides  the  following  two 
rules  will  help  in  this  situation: 


RULE  X [how  to  handle  an  unanswered  urgent  call  when  there 

is  no  alternate  number  but  the  home  number  is 
known] 

IF:  the  status  of  the  call  is  "not  answered"  & 

the  priority  of  the  call  is  "urgent"  & 
the  target  of  the  call  is  "primary  phone//"  & 
the  alternate_phone//  of  the  recipient  is  not  known  & 
the  home_phone//  of  the  recipient  is  known 

THEN:  set  the  target  of  the  ca  to  "home  phone//"  & 

set  the  status  of  the  call  "o  "to  be  initiated"; 


RULE  Y [how  to  handle  an  unanswered  call  if  no  other 

phone  numbers  are  known] 

IF:  the  status  of  the  call  is  "not  answered"  & 

the  alternate__phone/Z  of  the  recipient  is  not  known  & 
the  hone_phone//  of  the  recipient  is  not  known 


THEN:  set  the  desired_  placement  time  of  the  call  to 

currenttime  + 30  [minutes]  & 
set  the  status  of  the  call  to  "*-o  be  initiated"; 


We  note  that  since  this  is  a rule  set  in  which  the  order  of  the  rules 
is  not  important,  the  user  may  include  these  rules  anywhere,  e.g.,  at 
the  end  of  the  existing  rule  set.  We  believe  that  a computer-naive 
user  might  well  not  have  easily  accomplished  the  initial  eight-rule 
set  to  handle  his  telephone  calls,  but  given  that  set  as  an  initial 
starter  package — which  establishes  the  vocabulary  and  basic  logic  of 
the  approc^n — we  can  imagine  him  adding  Rules  X and  Y by  copying  the 
phrases  of  the  original  rules  with  some  minor  repackaging  and  modifi- 
cation. This  assumption  has  not  yet  been  tested  with  actual  computer- 
naive  users,  but  it  is  part  of  the  RITA  design  philosophy  that  this 
type  of  incremental  enhancement  to  existing  user  agents  be  allowed. 


j. 
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The  following  is  an  example  of  a trace  of  the  above  rule-directed 
user  agent  in  operation.  Although  various  amounts  of  detail  of  the 
operation  of  this  agent  might  be  shown,  we  show  here  only  the  names 
of  rules  whose  LHS  patterns  were  discovered  to  be  "true,"  i.e,,  matched 
by  data  in  the  context,  during  a hypothesized  operation  of  this  agent. 
We  assume  that  initially  there  exists  in  the  context  a "recipient" 
with  the  attributes  and  values  shown  at  the  beginning  of  this  appendix. 


Rule  Applied  Comment 


Interaction  With  User 


Rule  1 
Rule  2 

Rule  5 
Rule  2 
Rule  6 

Rule  2 

Rule  3 

Rule  2 

Rule  4 


creates  call  object 

invokes  rules  for 
sending  a call  to 
the  phone  system 

not  answered,  so  try 
alternate  number 

alternate  call  tried 
by  invoked  rule  set 

not  answered,  so  set  up 
to  retry  primary  call 
30  minutes  later 

after  30-minute  delay, 
primary  number  tried 
by  invoked  rule  set 

busy,  so  set  up  to 
retry  call  2 minutes 
later 

after  2-minute  delay, 
primary  number  tried 
by  invoked  rule  set 

call  is  answered  "Bob  Jones  has  been  reached 

at  his/her  primary  phone//. 
Please  pick  up  your  phone." 


The  user  could  of  course  monitor  the  progress  of  calls  by  inserting 
additional  action  clauses  into  those  rules  that  set  up  a call  to  be 
retried  later;  these  action  clauses  could  record  statements  such  as: 


"Busy  signal  on  your  call  to  Bob  Jone‘'.  Will  retry  in  2 min." 
"No  answer  on  your  call  to  Bob  Jones.  Will  retry  In  30  mm." 
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If  such  interaction  is  too  verbose,  the  user  has  the 
cally  interrupting  the  agent  and  inquiring  as  to  the 
the  status  and  desired  placement  time  of  the  call. 


option  of  periodi- 
current  values  of 


GOAL-DIRECTED  OPERATION 

As  an  example  of  goal-directed  monitor  operation,  consider  a set 
of  rules  which  performs  the  task  mentioned  in  the  previous  subsection: 
deciding  whether  a particular  "desired  placement  time,"  within  the 
time  zone  of  the  recipient,  for  a call  is  within  or  outside  scheduled 
business  hours,  or  during  the  lunch  hour.  In  describing  the  logic 
to  be  used  in  making  this  decision,  the  following  objects,  attributes, 


values 

will  be  used  as 

the 

vocabulary : 

Ob  j ect 

A 1 1 r ibute 

Sample  Va lues 

Comment 

recipient 

phono# 

"(21:)  393-0411” 

area  code  is  charac- 
ter^ 2-4  of  the 
phone  number 

a re  decile 

”213" 

extracted  from  phone 
number  by  rules 

time  offset 

”15",  etc. 

time  offset  of  re- 
cipient’s local 
time  zone  from 
Greenwich  Mean  Time 

ra L ler 

a re a code 

”415" 

area  code  of  caller 

time  offset 

"15",  etc. 

time  offset  of  cal- 
ler's local  time 
zone  from  Green- 
wich Mean  Time 

cal  1 

desi  red_plaeeir.ent 

t iiue 

”75/7/20  1545” 

cal lor's  local  » ime 

time  dec.  ci  ip  tor 

"within  bus.  hrs" 
"cutside  bus.  hrs" 
"lunch  hour" 

determined  hv  re- 
e i p lent ' loca i 
t ime 

recipients  local_ 

t ime 

"75/7/20  1545" 

translation  of  de- 
sired placement 
time  inco  recipi- 
ent's local  time 

t iraezone 

name 

"Eastern" 
"Central" 
"M'-  ota In" 
" ac  i f Ic" 

time  offset 

"12",  et*' . 

from  Greenwich.  Mean 
Tire 

nreacode  set 

("201",  "215",...) 

set  of  area  codes  In 
that  time  zone 

NOTH: 

We  assume  there  are  multiple  objects  ..4  type 

"time  zone"  in  the 

context,  each  having  specific  data  about  one  time  /.one  of  interest. 
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For  simp  ir  in  this  example,  we  have  shown  only  one  "phone#"  for  the 
recipient,  ; 'er  than  the  three  possible  numbers  used  in  the  previous 
example.  In  practice,  the  area  code  would  be  selected  from  the  target 
phone  number.  We  are  also  ignoring  the  calendar  date  of  the  call, 
which  might  be  used  to  distinguish  weekdays  from  weekends,  etc. 

The  type  of  deductive  logic  needed  to  derive  the  time  descriptor 
for  the  call  from  other  available  information  can  be  diagrammed  as 
follows : 


To  know  the  call's  time  descriptor,  v*  need  to  know* 

o the  recipient's  local  time  (corresponding  to  the 
call's  desired  placement  time),  tnd  to  know 
that,  we  need: 

o the  call's  desired  placement  time,  which  is 
available,  and 

o the  caller's  time  offse  , \shich  is  available, 
and 

o the  recipient's  “ime  offset,  and  to  know  that 
we  need: 

o the  recipient's  tine  zone,  and  to  know 
that  we  need: 

o the  recipient's  area  code,  which  is 
available. 


The  above  type  of  logic  is  well  suited  to  a goal-directed  approach. 
The  following  rules  encode  the  process.  Their  operation  is  triggered 
by  the  action  clause:  DEDUCE  the  rime  descriptor  of  the  call. 

[RULEb  FOR  DETERMINING  THE  TIME  DESCRIPTOR  FOR  A CALL] 


Rule  A [when  to  sot  the  descriptor  to  "lunch  hour"] 

IF:  the  recipients_local  time  of  the  call  Is  greater  than  or 

equal  to  1200  a 

the  recipients_local_time  of  the  call  is  less  than  or 
equal  to  1300 

THEN:  set  the  time_descriptor  of  the  call  to  "lunch  hour"; 
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Rule  B 
IF: 

THEN: 


[when  to  set  the  descriptor  to  "within  bus.  hrs"] 

the  recipients_local_time  of  the  call  is  greater  than  or 
equal  to  0800  & 

the  reci.pients_local_t.ime  of  the  call  is  less  than  12.00 
set  the  time  descriptor  of  the  call  to  "within  bus.  hrs"; 


Rule  C [another  "within  bus.  hrs"  possibility] 

IF:  the  recipients_local_t:ime  of  the  call  is  greater  than  1300  & 
the  recipients_local_time  of  the  call  is  less  than  or 
equal  to  1700 


THEN:  set  the  time_descriptor  of  the  call  to  "within  bus.  hrs"; 


Rule  D 
IF: 


THEN: 


[when  the  descriptor  is  "outside  bus.  hrs"] 

the  recipients_local_time  of  the  call  is  greater  than  1700  OR 
the  recipients_local_time  of  the  call  is  less  than  0800 

set  the  time_de8criptor  of  the  call  to  "outside  bus,  hrs"; 


Rule  E [how  to  compute  the  recipient’s  local  time] 

IF:  the  time_offset  of  the  recipient  is  known  & 

the  time_offset  of  the  caller  is  known  & 
the  desired_placemcnt_time  of  the  call  is  known 

THEN:  set  the  recipients_local_time  of  the  call  to 

the  desired_placement  _time  of  the  call  + 

(the  time_offset  of  the  caller  - the  time_cf fset 
of  the  recipient) ; 


Rule  F [how  to  compute  the  time  offset  of  the  recipient] 

IF:  the  areacode  of  the  recipient  is  a member  of  the 

areacode_set  of  a timezone  (T) 

THEN:  set  the  time_-»Jfset  of  the  recipient  to  the  time_offset 

of  the  timezone  (T)  ; 


Rule  G [how  to  compute  the  time  offset  of  the  caller] 

IF:  the  areacode  of  the  caller  is  a member  of  the 

areacode_set  of  a timezone  (T) 

THEN:  set  the  tirae__offset  of  the  caller  to  the  time_offset  of 

the  timezone  (T) ; 
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Rule  H [how  to  find  the  area  code  of  the  recipient] 

IF : the  phone#  of  the  recipient  is  known 

THEN:  set  the  areacode  of  the  recipient  to  substr(2,3,  phone#  of 

the  recipient) ; + 

To  a programmer , the  above  rule  set  may  seem  an  excessive  amount  of 
verbiage  to  encode  rather  simple  logic.  However,  the  rule  set  pos- 
sesses (at  least)  two  important  features:  it  can  be  modified  and  ex- 

tended quite  easily,  and  a monitor  can  use  it  to  give  an  explanation 
of  its  behavior. 

This  rule  set  could  be  extended,  as  mentioned  above,  by  adding 
rules  for  determining  whether  a date  is  a weekday  or  a weekend.  The 
given  rules  for  setting  the  time  descriptor  to  either  "within  bus.  hrs" 
or  "lunch  hour"  would  then  be  given  an  additional  clause  requiring  the 
condition  that  the  date  of  the  call  be  a weekday. 

As  an  example  of  possible  trace  information  which  could  be  gen- 
erated from  the  above  rule  set  in  response  to  a user's  requests,  con- 
sider the  following  excerpt  of  dialog.  (RITA's  responses  are  shown 
capitalized  only  to  distinguish  them  from  the  user’s  comments.) 

User  RITA 


What  did  you  do? 

THE  TIME_DESCRIPTOR  OF  THE  CALL  WAS  SET  TO  "outside  bus.  hrs" 

Why? 

BECAUSE  RULE  D WAS  APPLIED: 

IF:  THE  RECIPIENTS_LOCAL  TIME_  OF  THE  CALL  IS  GREATER  THAN  1700  OR 

THE  RECIPIENTS_LOCAL_TIME  OF  THE  CALL  IS  LESS  THAN  0800 

THEN:  THE  TIME  DESCRIPTOR  OF  THE  CALL  IS  "outside  bus.  hrs"; 


We  assume  the  availability  of  a "substring"  function;  substr (i ,n,x) 
extracts  n characters  from  string  x starting  at  location  i. 


TiT'T'TmiI  - ‘f  ' "r‘i  i i * »Ti * > i 


What  was  the  recipients_local_time  of  the  call? 

1745 

Why?  [interpreted  as:  hew  did  it  get  set  to  that  time?] 

BECAUSE  RULE  E WAS  APPLIED: 

IF:  THE  TIME__OFFSET  OF  THE  PJECIPIENT  IS  KNOWN  & 

THE  TIMEjOFFSET  OF  THE  CALLER  IS  KNOWN  & 

THE  DE  S I RED_PLACEMENT__T  I ME  OF  THE  CALL  IS  KNOWN 

THEN:  THE  REC IP IFNTS_LOCAL_T IME  OF  THE  CAI.L  IS 

THE  DLSIRED_PLACEMENT_TIME  OF  THE  CALL  + 

(THE  T1ME__0FFSET  OF  THE  CALLER  - THE  TIME  OFFSET 
OF  THE  RECIPIENT) ; 

What  was  the  desired_placement_time  of  the  call? 


. . .etc. 


We  note  that  in  addition  to  building  a user's  confidence  in,  and 
familiarity  with,  the  operation  of  his  system,  the  "why?"  facility 
also  helps  him  create  and  debug  new  or  modified  rule  sets.  Although 
at  a high  level,  he  is  still  programming  and  probably  must  debug  In 
some  form  whenever  a significant  change  is  made  to  a rule  set:. 
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